Load Test v mobilním vývoji — co to je, scénáře a jak se provádí

Co je Load Test?

Load Test (zátěžové testování) je proces kontroly, jak systém funguje při očekávaném počtu současných požadavků nebo uživatelů. V kontextu mobilního vývoje se Load Test aplikuje jak na serverovou část (API, databáze, cache), tak na klientskou část (zpracování push notifikací, synchronizace dat). Hlavní rozdíl oproti stress testování — Load Test modeluje reálné, nikoli extrémní zatížení. Podle AWS Well-Architected Framework (2024) by se zátěžové testování mělo provádět pomocí zátěžových profilů založených na reálné analytice používání.

Load Test lze provádět na úrovni HTTP požadavků na API, na úrovni připojení WebSocket nebo na úrovni databázových transakcí. Cílem je zajistit, aby doba odezvy každého požadavku nepřekročila stanovenou hranici (obvykle 500–1000 ms pro API) a propustnost (RPS — requests per second) odpovídala požadavkům. Google Cloud Armor (2024) stanovuje prahové hodnoty na základě percentilů: p95 doby odezvy by neměl překročit 2 sekundy u kritických endpointů.

Zátěžové testování mobilního backendu zahrnuje simulaci typických scénářů: registrace, autorizace, načítání feedu, odesílání formuláře. Scénáře se zaznamenávají ve formě HAR souborů (HTTP Archive) a reprodukují se nástrojem pro zátěžové testování. Podle dokumentace k6 (2025) umožňuje HAR konverze zkrátit dobu přípravy Load Testu o 60 %.

Cíle zátěžového testování

Prvním cílem Load Testu je potvrzení propustnosti systému. Pokud specifikace vyžaduje zpracování 1000 RPS, musí to zátěžový test potvrdit s rezervou 20 %. Podle Netflix Tech Blog (2024) se zátěžové testování v Netflixu provádí s rezervou 2x oproti špičkovému zatížení: pokud se očekává 10000 RPS, test kontroluje 20000 RPS. Tento přístup zaručuje stabilitu při náhlých výkyvech provozu.

Druhým cílem je identifikace úzkých míst (bottlenecks) v architektuře. Typická úzká místa v mobilních backendech — databáze (pomalé dotazy), cache (nesprávná strategie invalidace) a externí API (pomalé služby třetích stran). Distributed tracing (Jaeger, Zipkin) pomáhá lokalizovat problém na úrovni konkrétní služby nebo požadavku.

Třetím cílem je určení bodu nasycení (saturation point). To je okamžik, kdy přidávání nových uživatelů přestává zvyšovat propustnost. V mobilních aplikacích nastává bod nasycení často při 70–80 % vytížení CPU na databázových serverech. Auto-scaling by měl zasáhnout před dosažením tohoto bodu.

Scénáře zátěžového testování

Špičkové zatížení (Spike Test) — modeluje náhlý nárůst aktivity, například ranní rozesílku push notifikací nebo spuštění reklamní kampaně. Podle Grafana k6 (2025) Spike Test simuluje růst zatížení ze 100 na 10000 RPS během 30 sekund. Systém by to měl zvládnout bez ztráty požadavků a bez překročení doby odezvy o více než 50 %.

Konstantní zatížení (Endurance Test) — kontrola stability systému při dlouhodobém provozu pod zatížením. Typická doba trvání — 1–4 hodiny. Endurance Test odhaluje úniky paměti v serverových aplikacích, problémy s fondem připojení k databázi a degradaci výkonu cache. Fond připojení PostgreSQL při dlouhodobém zatížení bez správné konfigurace může vyčerpat dostupná připojení během 2–3 hodin provozu.

Stupňovité zatížení (Step Load Test) — postupné zvyšování zatížení s krokem 10–20 % každé 2–5 minut. Tento scénář pomáhá najít přesnou hranici, po které systém degraduje. InfluxDB a Prometheus sbírají metriky v každém kroku pro sestavení grafu závislosti doby odezvy na RPS.

Metriky Load Testu

Doba odezvy

Doba odezvy (Response Time) — hlavní metrika Load Testu. Měří se v milisekundách a analyzuje se podle percentilů: p50 (medián), p95 a p99. Google SRE (2024) doporučuje práh p95 ne více než 1000 ms pro REST API a ne více než 200 ms pro gRPC. Percentily jsou důležitější než průměr, protože ukazují chování nejhorších požadavků, kterých si uživatelé všimnou jako prvních. Apdex (Application Performance Index) — složená metrika zohledňující podíl spokojených, tolerantních a zklamaných uživatelů.

Propustnost

Propustnost (Throughput) — počet úspěšných požadavků za jednotku času. Měří se v RPS (requests per second) nebo TPS (transactions per second). Graf Throughputu v souřadnicích „čas — RPS“ by měl být lineární až do bodu nasycení. Náhlý pokles Throughputu při zvýšení zatížení — známka dosažení limitu systému. Apache Bench a wrk — jednoduché CLI nástroje pro rychlou kontrolu Throughputu ve fázi vývoje.

Procento chyb

Procento chyb (Error Rate) — podíl odpovědí s HTTP statusem 4xx nebo 5xx z celkového počtu požadavků. Povolený práh — méně než 1 %. Chyby 429 (Too Many Requests) a 503 (Service Unavailable) při vysokém zatížení naznačují potřebu konfigurace rate limittingu a auto-scalingu. Rate limiter na straně API Gateway chrání backend před překročením povoleného zatížení. Retry policy s exponenciálním zpomalením pomáhá klientům správně zpracovávat dočasné chyby.

Nástroje pro Load Test

k6 (Grafana)

k6 — přední Open Source nástroj pro zátěžové testování od Grafany. Skripty se píšou v JavaScriptu, podporují modulární scénáře, prahy (thresholds) a integraci s Prometheem a InfluxDB. k6 lze spouštět jak v CLI, tak v cloudu Grafana Cloud k6. Grafana Cloud automaticky vytváří dashboardy podle výsledků Load Testu a porovnává je s historickými daty. k6 podporuje Protocol Buffers a gRPC prostřednictvím samostatného modulu k6/net/grpc.

Apache JMeter

Apache JMeter — klasický nástroj pro Load Test s grafickým rozhraním. Podporuje širokou škálu protokolů: HTTP, JDBC, JMS, FTP a TCP. JMeter se lépe hodí pro složité scénáře s mnoha různými typy požadavků, ale vyžaduje více ruční konfigurace ve srovnání s k6. JMeter Plugins rozšiřují funkčnost pro testování WebSocket a gRPC. Pro distribuované spouštění používá JMeter architekturu master-slave s jedním řadičem.

Locust

Locust — nástroj založený na Pythonu, který umožňuje popisovat zátěžové scénáře v kódu. Locust je vhodný pro týmy, které používají Python jako hlavní jazyk pro automatizaci. Na rozdíl od k6 a JMeteru podporuje Locust distribuované spouštění přímo z krabice: jeden master-node koordinuje několik worker-nodů. Distribuované spouštění umožňuje generovat zatížení až 100000 RPS z několika strojů. Locust také podporuje WebSocket testování prostřednictvím vlastních rozšíření.

import http from 'k6/http'
import check from 'k6'
import sleep from 'k6'

export const options = {
    stages: [
        { duration: '2m', target: 100 },
        { duration: '5m', target: 100 },
        { duration: '2m', target: 200 },
    ],
    thresholds: {
        http_req_duration: ['p(95)<500'],
        http_req_failed: ['rate<0.01'],
    }
}

export default function() {
    const res = http.get('https://api.example.com/users')
    check(res, {
        'status is 200': (r) => r.status === 200,
    })
    sleep(1)
}

Příklad napsání Load Testu v k6

Výše uvedený skript k6 ukazuje typickou strukturu zátěžového testu. Options definuje profil zatížení: ramp-up 2 minuty na 100 uživatelů, poté 5 minut konstantního zatížení a opět ramp-up na 200 uživatelů. Thresholds nastavují kritéria pro úspěšné absolvování testu: p95 doby požadavku ne více než 500 ms, procento chyb méně než 1 %. Pokud jsou prahy překročeny, k6 ukončí test s nenulovým kódem — to umožňuje integraci Load Testu do CI/CD.

V mobilním vývoji je Load Test serverové části obzvláště důležitý při spouštění nových funkcí, které vytvářejí dodatečné zatížení: lajky, komentáře, streamování. Doporučení — provádějte Load Test na každém stagingu před nasazením do produkce. Vytvoření základního zátěžového profilu ve fázi návrhu API pomáhá vyhnout se architektonickým problémům v pozdějších fázích.