Apache Benchmark (ApacheBench, ab) – testowanie wydajności WWW w praktyce

W tym przewodniku poznasz instalację, praktyczne użycie, interpretację wyników oraz optymalizację na podstawie danych z testów.

Czym jest Apache Benchmark i dlaczego jest ważny dla właścicieli stron internetowych

Apache Benchmark to narzędzie projektu Apache HTTP Server do testów wydajności dla praktycznie każdego serwera WWW obsługującego HTTP/1.0 i HTTP/1.1 (w tym HTTPS). Mimo nazwy nie jest ograniczone do Apache – współpracuje z dowolnym serwerem HTTP. Jest dostępne jako wolne oprogramowanie (licencja Apache), bezpłatne do pobrania, instalacji i modyfikacji.

Znaczenie AB wynika z wpływu prędkości ładowania na doświadczenie użytkownika i pozycjonowanie. Pomiar i optymalizacja wydajności są niezbędne, by identyfikować wąskie gardła, weryfikować efekty zmian i utrzymywać stabilną szybkość działania witryny.

Dla początkujących webmasterów AB jest łatwe w użyciu: kilka podstawowych parametrów wystarczy, by poznać RPS (requests per second) i średnie czasy odpowiedzi. Prostota połączona z mocą czyni Apache Benchmark narzędziem idealnym do regularnego monitoringu.

Kluczowe cechy i możliwości Apache Benchmark

AB wysyła określoną liczbę żądań HTTP do wskazanego URL i mierzy kluczowe metryki: czas odpowiedzi, liczbę żądań na sekundę oraz przepustowość. Zdolność do symulacji równoczesnych żądań pozwala sprawdzić zachowanie serwera pod obciążeniem.

Najważniejsze możliwości w skrócie:

• współbieżność – testowanie wielu równoległych żądań i reakcji serwera pod obciążeniem;
• parametryzacja – kontrola liczby żądań (-n), współbieżności (-c), metody HTTP, nagłówków i danych;
• eksport wyników – zapisy do CSV (-e) i do formatu dla gnuplot (-g) do wizualizacji;
• funkcje zaawansowane – Basic Auth, cookies, własne timeouty, poziomy logowania (-v).

Możliwość zapisu wyników do CSV oraz formatu gnuplot ułatwia porównywanie testów w czasie i raportowanie trendów.

Instalacja Apache Benchmark na różnych systemach operacyjnych

Instalacja jest szybka i prosta, a szczegóły zależą od systemu operacyjnego.

Linux (Debian/Ubuntu) – wykonaj aktualizację pakietów i instalację zestawu narzędzi:

sudo apt update
sudo apt install apache2-utils

Windows – pobierz prekompilowane pliki ab.exe i abs.exe z serwisu apachelounge.com, rozpakuj i skopiuj do katalogu w PATH, aby uruchamiać z dowolnego miejsca.

macOS – w wielu wersjach AB jest dostępny wraz z systemem; uruchom Terminal i sprawdź dostępność.

Po instalacji zweryfikuj wersję narzędzia, aby potwierdzić, że wszystko działa poprawnie:

ab -V

Podstawowe użycie i kluczowe parametry wiersza poleceń

Najprostsza komenda to nazwa programu ab i adres URL testowanej strony. Aby uzyskać wartościowe dane, skonfiguruj -n (liczba żądań) i -c (współbieżność).

Przykład podstawowy:

ab -n 1000 -c 10 https://przykladowa-strona.pl/

Ważny detal: na końcu adresu URL musi znaleźć się ukośnik /. Przykład akceptowany: https://przykladowa-strona.pl/.

Najważniejsze przełączniki, które przyspieszają pracę z AB:

• -n – całkowita liczba żądań w teście (np. 100, 1000, 10 000);
• -c – liczba równoczesnych żądań (symulacja jednoczesnych użytkowników);
• -p/-u – wysyłanie danych w metodach POST/PUT z pliku (np. -p dane.json);
• -T – ustawienie nagłówka Content-Type (np. -T application/json);
• -H – dodatkowe nagłówki HTTP (np. -H "Authorization: Bearer token123");
• -A – Basic Auth (login:hasło zakodowane automatycznie do Base64);
• -k – Keep-Alive (utrzymywanie połączenia między żądaniami);
• -v – poziom szczegółowości logowania (np. -v 3 lub -v 4);
• -e/-g – eksport wyników do CSV i formatu gnuplot do wykresów.

Wysyłanie danych w żądaniu POST (przykład API z JSON):

ab -p dane.json -T application/json -n 100 -c 10 https://przykladowa-api.pl/

Interpretacja wyników i zrozumienie kluczowych metryk

Wynik AB zawiera wiele liczb, ale kilka wskaźników pozwala szybko ocenić kondycję serwera.

Najważniejsze metryki i jak je czytać:

• Requests per second (RPS) – średnia liczba żądań obsłużonych na sekundę; wyższa wartość oznacza lepszą skalowalność;
• Time per request – średni czas obsługi pojedynczego żądania; istotniejszy jest wariant rzeczywisty (bez dzielenia przez współbieżność);
• Percentage served within a certain time – percentyle czasów odpowiedzi; zwłaszcza 90. i 99. percentyl wskazują realne doświadczenia większości użytkowników;
• Failed requests – liczba błędnych żądań; warto użyć -v 3/-v 4, by zobaczyć kody statusu i rozróżnić np. 404/403/500;
• Transfer rate – przepustowość transferu (KB/s lub MB/s), pomocna przy ocenie wydajności treści statycznych.

Dla celów praktycznych najważniejsze są RPS, rzeczywisty Time per request i górne percentyle, które pokazują sporadyczne spowolnienia.

Zaawansowane scenariusze testowania i techniki

AB świetnie sprawdza się w testach sekwencji kroków (np. logowanie → dostęp do chronionego zasobu), choć złożone scenariusze wymagają skryptów opakowujących lub sięgnięcia po Apache JMeter czy Gatling.

Aby zasymulować zachowanie użytkowników w e-commerce, można uruchamiać serię testów: przeglądanie kategorii, wyszukiwanie, dodanie do koszyka, checkout. Proste skrypty + AB często wystarczą dla małych i średnich witryn.

Warto testować z różnych lokalizacji geograficznych (np. VPS w kilku regionach), aby sprawdzić wpływ opóźnień sieciowych i działania CDN. Testy skrajnego obciążenia (stress/spike) pomagają oszacować punkt załamania i planować skalowanie.

Typowe błędy i jak ich unikać

Świadomość najczęstszych pułapek pozwala uzyskać wiarygodne, porównywalne wyniki testów:

• zbyt wysoka współbieżność – start od -c 5–10 i stopniowe zwiększanie; unikniesz sztucznego przeciążenia i fałszywych wniosków;
• ignorowanie cache – uruchamiaj testy wielokrotnie, rozważ wyłączenie cache lub użycie -k, porównuj wyniki „na zimno” i „na ciepło”;
• zły scenariusz testowy – testuj ścieżki, które realnie odwiedzają użytkownicy (strona główna, logowanie, produkt, koszyk), a nie tylko zasoby statyczne;
• brak rozgrzewki – wykonaj krótki pre-test (np. 100 żądań), aby „rozgrzać” aplikację, cache i kompilacje JIT;
• brak monitoringu zasobów – równolegle obserwuj CPU/RAM/dysk I/O (np. top, htop, iostat) w celu identyfikacji wąskich gardeł.

Porównanie Apache Benchmark z innymi narzędziami do testowania wydajności

AB jest najszybsze w nauce i najlżejsze, lecz ma mniejszą elastyczność scenariuszy niż Apache JMeter i Gatling. Dla szybkich testów i prostych przypadków AB jest bezkonkurencyjne, a dla złożonych scenariuszy warto rozważyć JMeter lub Gatling.

Poniższa tabela ułatwia wybór narzędzia pod konkretne potrzeby:

Aspekt	Apache Benchmark	Apache JMeter	Gatling
Łatwość użycia	Bardzo prosta, tylko wiersz poleceń	Średnia, posiada GUI, ale stroma krzywa uczenia	Wymagająca wiedzy technicznej
Interfejs	Wiersz poleceń	GUI + wiersz poleceń	Kod (Scala/Java)
Obsługiwane protokoły	HTTP/HTTPS	HTTP, FTP, LDAP, JDBC, WebSocket	HTTP/HTTPS, WebSocket
Maksymalne obciążenie	Średnie (setki użytkowników)	Wysokie (tysiące użytkowników)	Bardzo wysokie (miliony użytkowników)
Zużycie zasobów	Minimalne	Średnie do wysokiego	Niskie–średnie
Raportowanie	Proste, tekstowe	Zaawansowane, generowanie HTML	HTML i JSON
Integracja z CI/CD	Minimalna	Dobra	Doskonała
Koszt	Bezpłatne	Bezpłatne	Bezpłatne (z opcją Gatling Enterprise)

Praktyczne zastosowania w rzeczywistych scenariuszach

Oto najczęstsze i najbardziej wartościowe sposoby wykorzystania AB w codziennej pracy:

• regularne monitorowanie wydajności – cykliczne testy (miesięczne/kwartalne) wykrywają regresje po wdrożeniach i wzroście danych;
• weryfikacja efektów optymalizacji – szybkie sprawdzenie wpływu zmian (kompresja, cache, refaktoryzacja) na RPS i czasy odpowiedzi;
• testy przed kampaniami marketingowymi – symulacja skoków ruchu i ocena odporności infrastruktury na chwilowe piki;
• porównanie konfiguracji serwera – obiektywne zestawienie wyników (np. Apache vs Nginx, zmiana hostingu, wersje PHP/DB);
• diagnozowanie zgłoszeń użytkowników – testy z różnych regionów oraz pod obciążeniem, aby odtworzyć trudne warunki.

Strategie optymalizacji oparte na wynikach testów

Dobierz działania do zaobserwowanych metryk i symptomów:

• niski RPS (np. < 10) – szukaj wąskich gardeł; gdy CPU = 100%, optymalizuj kod, przenoś ciężkie zadania do asynchronicznych workerów lub zwiększ zasoby;
• wysokie zużycie RAM – podejrzenie wycieków/nieoptymalnych sesji; optymalizacja kodu, zwiększenie pamięci, wdrożenie cache (Redis, Memcached);
• wąskie gardło dysk I/O – sprawdź iostat; użyj szybszego storage (SSD/NVMe), indeksuj zapytania, optymalizuj bazę danych;
• długie czasy odpowiedzi przy rozsądnym RPS – kompresja gzip, redukcja rozmiaru zasobów, CDN dla statyk, optymalizacja HTML/JS/CSS;
• problemy w górnych percentylach (np. 99.) – zidentyfikuj źródła sporadycznych skoków (GC, zapytania DB, fluktuacje sieci), dostrój GC i konfigurację serwera WWW.