ab -k -t 10 -c 50 https://informatik.hs-bremerhaven.de/direct
# ~ 35000 rps    

ab wirkt mittlerweile vielleicht etwas veraltet, ist aber für den ersten Wurf immer noch gut. Die drei Schalter (t=time in seconds, k=keepalive, c=concurrency) sollte man sich merken. Alternativ zu -t lässt sich mit -n auch die Gesamtanzahl der Requests angeben.

ab sendet keine cookies zurück, ist daher für session-basierte Anwendungen eher ungeeignet.

Wenn es jedoch um reine RPS-Performance geht, genügend Kerne auf der Test-Maschine vorhanden sind und mehrere ab-Instanzen gestartet werden, lassen sich damit bei uns gegen den haproxy über https gut und gerne 360000 RPS herausholen. Dafür muss dann aber der haproxy direkt antworten und nicht in der Rolle des Reverse-Proxies oder Loadbalancer Anfragen weiterleiten.

Ausschnitt aus youtube-Video

curl ist zunächst vor allem für api-Tests und Automatisierungen das Werkzeug der Wahl - insbesondere, da es das erste neben dem vim ist, was bei uns und vielen anderen installiert wird.

curl -s https://informatik.hs-bremerhaven.de/direct

Mit den Schaltern b und c lassen sich cookie-jars angeben, mit denen dann über Session-Grenzen hinweg Abfolgen an einen Server geschickt werden.

curl -s -b jar-$$ -c jar-$$ https://informatik.hs-bremerhaven.de/direct?t=[1-1000] 

So werden 1000 Requests mit einem Prozessaufruf sequenziell abgesetzt und es wird eine jar-Datei für die Cookies genutzt. Dafür sollte der curl-Aufruf aber unbedingt auf einem schnellen Dateisystem (/dev/shm) laufen. Insbesondere für einen Lasttest ist nfs weitaus zu langsam.

mkdir -p /dev/shm/$USER
cd /dev/shm/$USER
for i in {1..50}; do
  curl -s -b jar-$i-$$ -c jar-$i-$$ https://informatik.hs-bremerhaven.de/direct?t=[1-10000] >/dev/null &
done
wait

Es ist mal wieder erstaulich, wie weit man damit kommt. Etwa 40000 RPS sind mit dem obigen Aufruf möglich. Der Vorteil ist insbesondere das vorhandene Session-Handling: so lassen sich mit etwas Geschick ganze use-cases mit wenigen Zeilen zusammensetzen und auf einem Durchschnittsserver regelmäßig durchspielen.

Wenn aber die Lastgrenze wirklich ausgereizt werden soll, ohne dass ein ganzer, wirklich gut ausgestatteter Server dafür zur Verfügung steht, ist das gute, alte wrk im Zweifel das Werkzeug der Wahl. Auch hier lassen sich klassische Abläufe nicht einfach verskripten, da cookies und damit Session-ids normalerweise nicht mit zurückgeschickt zu werden scheinen, aber dennoch: ein gutes Werkzeug im Werkzeugkoffer. Wer Lust hat, kann sich aber am Verskripten mit Lua versuchen. wrk ist in den docker-Containern und auf hopper installiert.

wrk -c 1000 -t20 -d 10 https://informatik.hs-bremerhaven.de/direct

Damit sind problemlos 300000 Anfragen pro Sekunde möglich, die dann allerdings direkt von dem ha-proxy beantwortet werden müssen, ohne dass dieser die Anfragen noch weiterleitet. Wenn haproxy die Anfragen an einen gut ausgestatteten tomcat-Server weiterleitet, kommen wir zur Zeit so nicht über 30000 RPS hinaus. Da lässt sich sicherlich noch einiges herausfinden. Der tomcat - direkt angesprochen über http - ist selbst bei 120000 RPS nicht wirklich ausgelastet.

Ich experimentiere gerade selbst erst mit k6, muss aber sagen, dass es sich schon nach wenigen Stunden anfühlt, als ob es zu einem Standardwerkzeug werden könnte. Die Kombination von in Go geschriebenem Programm und Javascript als Ablaufskriptsprache macht es schnell und komfortabel. Bei uns ist es in den docker-Containern installiert.

Zunächst einmal benötigen wir eine javascript-Datei names script.js:

import http from 'k6/http';
export const options = {
  noCookiesReset: true,
}

export default function () {
  let jar = http.cookieJar();
  const res = http.get('https://informatik.hs-bremerhaven.de/direct');
}

Dieses Skript lässt sich dann mit der entsprechenden Zahl an virtuellen Usern und einer Dauer oder einer bestimmten Menge an Iterationen direkt ausführen:

k6 run --vus 1000 --iterations 1000000 script.js

Auch hier lassen sich auf einer gut ausgestatteten VM mit 32 Kernen gute 120000 https-Requests ohne Mehrarbeit herausholen. Was hier noch möglich ist, bleibt abzuwarten.