1. [Strona główna](/) › 2. [Baza wiedzy](/baza-wiedzy/) › 3. Testowanie wydajności serwera — k6 i ab # Testowanie wydajności serwera — k6, ApacheBench i wrk Opublikowano: 9 kwietnia 2026 · Kategoria: VPS / Wydajność ⚡ W skrócie · 9 min czytania - Jak testować wydajność serwera i aplikacji: k6 (scripting VUs, thresholds, CI/CD), ApacheBench ab (szybki benchmark), wrk (wielowątkowy). Interpretacja wyników: RPS, latencja, percentyle. - ApacheBench (ab) — szybki benchmark w jednej komendzie. - wrk — wielowątkowy benchmark HTTP. - k6 — load testing ze skryptami JavaScript. - Porównanie narzędzi load testowych. Kupujesz droższy VPS bo aplikacja "działa wolno"? Zanim przepłacisz, zmierz gdzie leży faktyczny bottleneck. Load testing pozwala zmierzyć ile requestów na sekundę obsługuje Twój stack, jakie jest P95 latencji i przy ilu użytkownikach jednocześnie serwis zaczyna się sypać. W tym przewodniku poznasz trzy narzędzia: ApacheBench do szybkich benchmarków, wrk do wielowątkowych testów i k6 do złożonych scenariuszy z integracją CI/CD. ## ApacheBench (ab) — szybki benchmark w jednej komendzie `ab` jest wbudowany w pakiet `apache2-utils` — nie wymaga instalacji serwera Apache. Działa jako klient HTTP wysyłający N żądań z C równoległymi połączeniami: sudo apt install -y apache2-utils # Składnia: ab -n LICZBA\_ŻĄDAŃ -c RÓWNOLEGŁOŚĆ URL # Test: 1000 żądań, 10 równolegle ab -n 1000 -c 10 https://example.com/ # Test z nagłówkiem (np. autoryzacja) ab -n 500 -c 20 -H "Authorization: Bearer TOKEN" https://api.example.com/v1/products # Test POST z body JSON ab -n 200 -c 5 \\ -T 'application/json' \\ -p payload.json \\ https://api.example.com/v1/orders # Zapisz wyniki do pliku CSV (gnuplot friendly) ab -n 1000 -c 50 -e results.csv https://example.com/ Przykład wyjścia ab z kluczowymi metrykami: Concurrency Level: 50 Time taken for tests: 3.241 seconds Complete requests: 1000 Failed requests: 0 Requests per second: 308.55 \[#/sec\] (mean) Time per request: 162.06 \[ms\] (mean) Time per request: 3.24 \[ms\] (mean, across all concurrent requests) Transfer rate: 412.33 \[Kbytes/sec\] received Percentage of the requests served within a certain time (ms) 50% 98 66% 112 75% 124 80% 134 90% 178 95% 234 98% 312 99% 389 100% 621 (longest request) **Interpretacja:** 308 RPS (requests per second), mediana 98ms, P95 = 234ms (95% żądań odpowiedziało w <234ms), maksimum 621ms. Dla normalnej strony statycznej: 1000+ RPS to dobry wynik na małym VPS. Dla PHP/Node.js: 100–500 RPS zależy od złożoności. ## wrk — wielowątkowy benchmark HTTP `wrk` jest szybszy od ab bo używa wielu wątków i asynchronicznych połączeń (epoll/kqueue). Idealny do sprawdzenia maksymalnej przepustowości serwera: \# Instalacja wrk sudo apt install -y wrk # lub build ze źródeł: # git clone https://github.com/wg/wrk && cd wrk && make # Podstawowy test: 4 wątki, 100 połączeń, przez 30 sekund wrk -t4 -c100 -d30s https://example.com/ # Z niestandardowym nagłówkiem i timeoutem wrk -t4 -c100 -d30s \\ -H "Accept-Encoding: gzip" \\ --timeout 10s \\ https://example.com/api/products # Skrypt Lua — POST request z JSON body wrk -t4 -c100 -d30s -s post.lua https://api.example.com/v1/data \-- post.lua — skrypt Lua dla wrk wrk.method = "POST" wrk.body = '{"user":"test","action":"login"}' wrk.headers\["Content-Type"\] = "application/json" -- Opcjonalnie: losowe dane per request local counter = 0 request = function() counter = counter + 1 local body = '{"id":' .. counter .. '}' return wrk.format(nil, nil, nil, body) end \# Wynik wrk: Running 30s test @ https://example.com/ 4 threads and 100 connections Thread Stats Avg Stdev Max +/- Stdev Latency 45.23ms 12.34ms 234.56ms 89.12% Req/Sec 543.21 45.67 612.00 78.45% 65123 requests in 30.03s, 89.45MB read Requests/sec: 2168.23 Transfer/sec: 2.98MB ## k6 — load testing ze skryptami JavaScript k6 (od Grafana Labs) to nowoczesne narzędzie do load testingu — testy piszesz w JavaScript, możesz modelować złożone scenariusze użytkowników i integrować z CI/CD przez thresholds: \# Instalacja k6 (Ubuntu/Debian) sudo gpg -k sudo gpg --no-default-keyring \\ --keyring /usr/share/keyrings/k6-archive-keyring.gpg \\ --keyserver hkp://keyserver.ubuntu.com:80 \\ --recv-keys C5AD17C747E3415A3642D57D77C6C491D6AC1D69 echo "deb \[signed-by=/usr/share/keyrings/k6-archive-keyring.gpg\] https://dl.k6.io/deb stable main" \\ | sudo tee /etc/apt/sources.list.d/k6.list sudo apt update && sudo apt install -y k6 Skrypt k6 z VU (virtual users), stages i thresholds — zapisz jako `test.js`: import http from 'k6/http'; import { check, sleep } from 'k6'; // Opcje testu export const options = { // Stages — ramp-up, plateau, ramp-down stages: \[ { duration: '30s', target: 10 }, // Ramp-up do 10 VU w 30s { duration: '1m', target: 50 }, // Skaluj do 50 VU przez 1 min { duration: '30s', target: 50 }, // Utrzymaj 50 VU przez 30s { duration: '30s', target: 0 }, // Ramp-down do 0 \], // Thresholds — kryteria sukcesu testu thresholds: { 'http\_req\_duration': \['p(95)<500'\], // P95 < 500ms 'http\_req\_failed': \['rate<0.01'\], // Mniej niż 1% błędów 'checks': \['rate>0.99'\], // >99% własnych checków OK }, }; // Domyślna funkcja — jeden wirtualny użytkownik export default function () { // Test strony głównej const homeRes = http.get('https://example.com/'); check(homeRes, { 'homepage: status 200': (r) => r.status === 200, 'homepage: < 300ms': (r) => r.timings.duration < 300, 'homepage: has title': (r) => r.body.includes(''), }); sleep(1); // 1 sekunda przerwy między iteracjami // Test API const apiRes = http.get('https://example.com/api/products', { headers: { 'Accept': 'application/json' }, }); check(apiRes, { 'API: status 200': (r) => r.status === 200, 'API: JSON body': (r) => r.headers\['Content-Type'\].includes('json'), 'API: < 500ms': (r) => r.timings.duration < 500, }); sleep(2); } \# Uruchom test k6 run test.js # Eksport wyników do JSON (dla dalszej analizy) k6 run --out json=results.json test.js # Integracja z Grafana (przez k6 Cloud lub InfluxDB) k6 run --out influxdb=http://localhost:8086/k6 test.js ## Porównanie narzędzi load testowych Narzędzie Język skryptów Złożoność scenariuszy CI/CD Kiedy używać ApacheBench (ab) Brak (CLI) Jeden endpoint Tak (exit code) Szybki benchmark, porównanie konfiguracji wrk Lua (opcjonalnie) Jeden endpoint + custom headers Ograniczone Maksymalna przepustowość, wielowątkowy test k6 JavaScript/TypeScript Złożone scenariusze Pełna (thresholds) Testy wieloetapowe, CI/CD, SLA verification Locust Python Złożone scenariusze Tak Zespoły znające Python, distributed testing JMeter XML + Groovy Pełne Tak Enterprise, protokoły nie-HTTP (JDBC, JMS) ## Interpretacja wyników — co oznaczają metryki - **RPS (Requests per Second)** — przepustowość serwera. Dla API REST: 500–5000 RPS to norma w zależności od złożoności. Dla statycznych plików: 10 000+ RPS na dobrym serwerze. - **P50 (mediana)** — połowa żądań odpowiedziała szybciej. Dobry punkt odniesienia dla "typowego użytkownika". - **P95 / P99** — 95% / 99% żądań odpowiedziało szybciej. P99 > 2× P95 sugeruje outliers — wolne zapytania SQL, cold starts, GC pause. - **Error rate** — procent żądań zakończonych błędem (5xx, timeout). Powyżej 1% to alarm. Powyżej 5% to katastrofa produkcyjna. - **Throughput vs Latency** — wzrost obciążenia zazwyczaj zwiększa latencję. Znajdź punkt "knee of the curve" — gdy latencja zaczyna rosnąć nieliniowo. ## Najczęstsze pytania Jakie jest różnica między load testing a stress testing? + Load testing sprawdza zachowanie aplikacji pod normalnym i oczekiwanym ruchem — np. 100 użytkowników jednocześnie przez 30 minut. Celem jest weryfikacja że system spełnia SLA (czas odpowiedzi < 500ms). Stress testing celowo przekracza limity systemu — zwiększasz obciążenie aż serwis zacznie się sypać, żeby znaleźć punkt graniczny (breaking point). Spike testing to nagły wzrost ruchu (np. 10x w ciągu 10 sekund) — symuluje flash sale lub viral post. Co to są thresholds w k6 i jak je definiować? + Thresholds (progi) to kryteria sukcesu testu k6 — jeśli nie zostaną spełnione, k6 zwraca kod wyjścia != 0 (przydatne w CI/CD). Przykłady: http\_req\_duration{"p(95)<500"} — 95% requestów musi odpowiedzieć w <500ms. http\_req\_failed{"rate<0.01"} — mniej niż 1% requestów może zakończyć się błędem. checks{"rate>0.99"} — ponad 99% własnych checków musi przejść. Thresholds definiujesz w obiekcie options.thresholds. Kiedy używać ApacheBench (ab) zamiast k6? + ApacheBench (ab) to idealne narzędzie do szybkiego testu pojedynczego endpointu — nie wymaga pisania skryptów, wystarczy jedno polecenie w terminalu. Używaj ab gdy: chcesz szybko sprawdzić ile requestów na sekundę obsługuje serwer, porównujesz konfiguracje (np. Nginx vs Apache, z i bez cache), potrzebujesz prostego benchmarku przed i po optymalizacji. k6 jest lepszy gdy testujesz złożone scenariusze (logowanie, koszyk, wielokrokowe formularze), potrzebujesz testów z danymi dynamicznymi albo integracji z CI/CD. Co oznacza percentyl p99 w wynikach testów wydajnościowych? + Percentyl p99 (99. percentyl) oznacza że 99% żądań odpowiedziało szybciej niż ta wartość — tylko 1% zajęło dłużej. Jeśli p99 = 2000ms, to 99 na 100 użytkowników dostało odpowiedź w <2s, ale jeden miał >2s. Dlaczego nie używać średniej? Średnia jest mylącą miarą — kilka bardzo wolnych żądań może ją zawyżyć, ale zamaskować dobrą wydajność dla większości. SLA zazwyczaj definiuje się przez p95 lub p99 bo opisują doświadczenie real użytkowników, nie arytmetykę. ## Sprawdź oferty pasujące do tego scenariusza Poniżej masz szybkie przejścia do ofert i stron z kodami rabatowymi tam, gdzie są dostępne. Contabo VPS do testów wydajnościowych — sprawdź ile requestów/s obsługuje Twój stack VPS [Aktywuj rabat →](/out/contabo/#reklama "Contabo") #Reklama · link partnerski [Zobacz kod rabatowy →](/kody-rabatowe/contabo) Mikrus Tani VPS — benchmarkuj konfiguracje Nginx/PHP zanim pójdziesz na większy serwer Benchmark [Aktywuj rabat →](/out/mikrus/#reklama "Mikrus") #Reklama · link partnerski [Zobacz kod rabatowy →](/kody-rabatowe/mikrus) LH.pl Hosting LiteSpeed — sprawdź w benchmarku różnicę vs Apache na tym samym projekcie LiteSpeed [Aktywuj rabat →](/out/lh-pl/#reklama "LH.pl") #Reklama · link partnerski [Zobacz kod rabatowy →](/kody-rabatowe/lh-pl) ## Powiązane strony - [Nginx load balancer — konfiguracja](/baza-wiedzy/nginx-load-balancer-konfiguracja) - [PHP-FPM — konfiguracja i optymalizacja](/baza-wiedzy/php-fpm-konfiguracja-optymalizacja) - [Zabbix — monitoring serwera](/baza-wiedzy/zabbix-monitoring-serwera) - [Wszystkie artykuły](/baza-wiedzy/) Autor: [Tomasz Nowosielski](/autorzy/tomasz-nowosielski) Redaktor naczelny, analityk hostingu · Zweryfikowano Czerwiec 2026 Od kilku lat analizuje rynek hostingowy w Polsce, śledząc zmiany cenników i regulaminów ponad dwudziestu dostawców. W HostGrade.pl odpowiada za metodologię kalkulatora TCO — narzędzia, które ujawnia rzeczywisty koszt hostingu przez dwa lata zamiast tylko cenę startową. Kalibruje rankingi hostingów pod kątem transparentności: wynik algorytmu, nie opinia sponsora. Specjalizuje się w analizie porównawczej hostingów współdzielonych, VPS i serwerów dedykowanych pod kątem stosunku ceny do wydajności. Pilnuje zgodności z dyrektywą Omnibus — każda przekreślona cena na serwisie musi mieć udokumentowaną historię. Pisze dla osób, które nie chcą dowiedzieć się o prawdziwej cenie odnowienia dopiero po roku płacenia ceny startowej. [Pełny profil autora →](/autorzy/tomasz-nowosielski)