Skip to content

Web server benchmark

Table of contents generated with markdown-toc

Opis

Do aktywnego monitoringu potrzebujemy benchmarków. Jednym z nich ma być serwer webowy. Oczekiwania wobec benchmarka:

  1. Konteneryzacja - nie musi być "oficjalna", może być utrzymywana przez nas. W przypadku nie utrzymywanych projektów z kontenerami preferowane przetrzymywanie lokalne.
  2. Uruchamianie benchmarka musi być ograniczalne zasobowo (ustalenie limitów prockowych i pamięciowych). Ograniczenie nie musi być wspierane przez benchmark, może być realizowane przez dockera/system.
  3. Benchmark ma zwracać conajmniej jedną metrykę liczbową, która będzie mogła być porównywana pomiędzy kolejnymi uruchomieniami.

Research

Materiały

Apache Bench

Źródło

https://httpd.apache.org/docs/2.4/programs/ab.html

Kontener

https://github.com/jig/docker-ab

Przykład

Odpalenie testowego serwera i potem benchmarku:

docker run -d -p 8080:8080 jordi/server:http
docker run --rm jordi/ab -k -c 100 -n 100000 http://172.17.0.1:8080/

Przydatne opcje

  • -t - timelimit - ograniczenie czasu

Nie widzę możliwości sterowania ilością CPU/RAM. Jest parametr -c, który steruje iloscią jednocześnie wysyłanych zapytań (ilość wątków?).

Przydatne metryki

  • Time taken for tests
  • Requests per second
  • Time per request

Koniecznie sprawdzić też Complete/Failed requests - czy benchmark jest miarodajny

Tym można zrobić dystrybuantę czasu odpowiedzi:

docker run -it --rm --mount type=bind,source=/tmp,target=/tmp jordi/ab -e /tmp/test -k -c 100 -n 100000 http://172.17.0.1:8080/

Siege

Źródło

https://github.com/JoeDog/siege/

Kontener

https://github.com/yokogawa-k/docker-siege

Przykład

    docker run --rm -t yokogawa/siege -d1 -r10 -c25 http://172.17.0.1:8080/
    docker run --rm -t yokogawa/siege --time=60S http://172.17.0.1:8080/

Przydatne opcje

  • -b - benchmark - brak opóźnień pomiędzy zapytaniami
  • -t - time - limit czasowy testu

Nie widzę możliwości sterowania ilością CPU/RAM. Też można sterować ilością jednoczesnych zapytań, ale zdaje się to nie zmieniać jakoś zuzycia CPU.

Przydatne metryki

  • Transaction rate

Uwagi

https://www.sonassi.com/blog/magento-kb/why-siege-isnt-an-accurate-test-tool-for-magento-performance

Httperf

Źródło

https://github.com/httperf/httperf

Kontener

https://github.com/dos65/docker-httperf

Przykład

docker run -v /tmp:/tmp dos65/httperf httperf --server 172.17.0.1 --port 8080 --num-conns=10000

Przydatne opcje

  • --rate - stress test

Przydatne metryki

  • Connection rate
  • Connection time
  • CPU time

Propozycja implementacji

Ze względu na to, że AFAIK apache bench jest zawarty w pakiecie apache (czy raczej httpd), najprościej będzie wykorzystać oficjane obrazy. Benchmark polegać będzie na stworzeniu dwóch kontenerów, spiętych docker-composem:

  • webserver testowy apache
  • tester, w którym będzie uruchomiony ab

W ab flagą -t można ustawić arbitralny timelimit, np. 30s. Jest też flaga -c, która pozwala na zdefiniowanie ilości jednoczesnych zapytań, aczkolwiek nie do końca wiem jak to się przekłada na ilość CPU.

IMHO najlepiej ograniczyć pamięć i CPU w konfiguracji kontenera ([https://www.baeldung.com/ops/docker-memory-limit]), wymaga to dokładniejszego zbadania.

Edited by Cyprian Kleist