Ich habe Python für einen Lasttest verwendet, und sehen Sie, was dann passierte...

Nachdem ich das Google Cloud Storage-Backend zu PrivateBin hinzugefügt hatte, war ich an dessen Leistungsmerkmalen interessiert. Um einen echten PrivateBin-Client vorzutäuschen, musste ich eine verschlüsselte Nachricht erzeugen.Ich suchte nach einer Client-Bibliothek und fand PBinCLI. Da sie in Python geschrieben ist,konnte ich einen einfachen Lasttest in Locust schreiben. Schön und einfach. Wie falsch ich doch lag.

den Test erstellen

Innerhalb weniger Minuten hatte ich ein Testskript zum Erstellen, Abrufen und Löschen einer Paste. Um die funktionale Korrektheit zu überprüfen, habe ich es gegen privatebin.net laufen lassen:

$ locust -f locustfile.py 
   --users 1 
   --spawn-rate 1 
   --run-time 1m 
   --headless 
   --host https://privatebin.net

Die folgende Tabelle zeigt die gemessenen Reaktionszeiten:

Name	Mittelwert (ms)	Min (ms)	Max (ms)	Median (ms)
erstellen-einfügen	237	140	884	200
get-paste	28	27	30	29
löschen-einfügen	27	27	29	27

Jetzt hatte ich ein funktionierendes Lasttest-Skript und eine Basislinie, mit der ich die Leistung vergleichen konnte.

Grundlinie auf Google Cloud Storage

Nachdem ich den Dienst auf Google Cloud Run bereitgestellt hatte, führte ich den Einzelnutzertest durch. Und er war vielversprechend.

$ locust -f locustfile.py 
  --users 1 
  --spawn-rate 1 
  --run-time 1m 
  --headless 
  --host https://privatebin-deadbeef-ez.a.run.app

Sicher, es ist nicht blitzschnell, aber das hatte ich auch nicht erwartet. Die Antwortzeiten sahen für michakzeptabel aus. Schließlich wird privatebin weder oft noch stark genutzt.

Name	Mittelwert (ms)	Min (ms)	Max (ms)	Median (ms)
erstellen-einfügen	506	410	664	500
get-paste	394	335	514	380
löschen-einfügen	587	443	974	550

Mehrbenutzerbetrieb auf Google Cloud Storage

Als nächstes wollte ich die Leistung von PrivateBin mit meinem Google Cloud Storage bei mäßiger Last testen. Also habe ich den Lasttest auf 5 gleichzeitige Nutzer skaliert.

$ locust -f locustfile.py 
  --users 5 
  --spawn-rate 1 
  --run-time 1m 
  --headless

Die Ergebnisse waren schockierend!

Name	Mittelwert (ms)	Min (ms)	Max (ms)	Median (ms)
erstellen-einfügen	4130	662	10666	4500
löschen-einfügen	3449	768	6283	3800
get-paste	2909	520	5569	2400

Und wie? Und warum? Gab es einen Engpass auf der Speicherebene? Ich habe die Protokolle überprüft und gesehen, dass Cloud Run konstante Antwortzeiten meldet:

POST 200 1.46 KB 142 ms python-requests/2.25.1  https://privatebin-37ckwey3cq-ez.a.run.app/
POST 200 1.25 KB 382 ms python-requests/2.25.1  https://privatebin-37ckwey3cq-ez.a.run.app/
GET  200 1.46 KB 348 ms python-requests/2.25.1  https://privatebin-37ckwey3cq-ez.a.run.app/?d7e4c494ce4f613f

Ich habe eine Weile gebraucht, um herauszufinden, dass Locust meinen kleinen M1 ruiniert hat. Er lief mit 100 % CPU-Leistung, ohne dassauch nur einen Lüfter anließ, um die verschlüsselten Nachrichten zu erstellen! Ich brauchte also etwas Effizienteres.

k6 zur Rettung!

Wenn mein Gehirn schnell denkt, denkt es an Golang. Also habe ich k6 heruntergeladen. Die Benutzerskriptesind in JavaScript geschrieben, aber die Engine ist rein go. Leider ist der Interpreter eine Sonderanfertigung und nur begrenzt kompatibel mit nodejs und Browser-JavaScript-Engines. Das bedeutete, dass ich keine vorhandenen JavaScript-Bibliotheken verwenden konnte, um eine verschlüsselte Nachricht zu erstellen.

Glücklicherweise können Sie mit xk6 eine golang Funktion von Ihrem JavaScript-Code aus aufrufen. Das war es, was ich brauchte! Also erstellte ich die k6 privatebin Erweiterung und schrieb ein entsprechendes Lasttest-Skript.

Bauen Sie einen maßgeschneiderten k6

Um diese neue Erweiterung zu verwenden, erstelle ich k6 lokal mit den folgenden Befehlen:

go install github.com/k6io/xk6/cmd/xk6@latest
xk6 build --with github.com/binxio/xk6-privatebin@v0.1.2

k6 Baseline läuft auf Google Cloud Storage

Jetzt war ich bereit, die Baseline für den Einzelbenutzer mit k6 auszuführen:

$ ./k6 --log-output stderr run -u 1 -i 100  test.js

Das Basisergebnis sah ziemlich genau so aus wie der Locust-Lauf:

Name	Mittelwert (ms)	Min (ms)	Max (ms)	Median (ms)
erstellen-einfügen	440	396	590	429
get-paste	355	320	407	353
löschen-einfügen	382	322	599	357

k6 Mehrbenutzerlauf auf Google Cloud Storage

Was würde passieren, wenn ich die Anzahl der gleichzeitigen Benutzer auf 5 erhöhe?

$ ./k6 --log-output stderr run -u 5 -i 100  test.js

Juhu! Die Reaktionszeiten sind ziemlich gleich geblieben.

Name	Mittelwert (ms)	Min (ms)	Max (ms)	Median (ms)
erstellen-einfügen	584	350	2612	555
get-paste	484	316	808	490
löschen-einfügen	460	295	843	436

Die folgende Tabelle zeigt die Summe der Mediane für den Einzel- und Mehrbenutzer-Lasttest auf Locust und k6:

Es ist klar, dass Locust die Ergebnisse viel zu sehr verzerrt hat. Mit k6 konnte ich sogar 20 gleichzeitige Benutzer simulieren und trotzdem nur 25% meines M1 nutzen.

Name	Mittelwert (ms)	Min (ms)	Max (ms)	Median (ms)
erstellen-einfügen	713	414	1204	671
get-paste	562	352	894	540
löschen-einfügen	515	351	818	495

Das sind viel mehr Benutzer, als ich bei meiner Privatebin-Installation erwarte, und diese Antwortzeiten sind für mich sehr akzeptabel. Mission erfüllt!

Fazit

In Zukunft wird mein bevorzugtesTool für Last- und Leistungstests k6 sein. Es ist eine einzelne Binärdatei, die Sie überall ausführen können. Es ist schnell und die Golang-Erweiterungen machen es einfach, rechenintensive Aufgaben auf eine sehr benutzerfreundliche Weise einzubinden.