Load Test a mobilfejlesztésben — Mi ez, forgatókönyvek és hogyan végezzük

Mi az a Load Test?

Load Test (terheléses tesztelés) — annak vizsgálata, hogy a rendszer hogyan működik az egyidejű kérések vagy felhasználók várható száma alatt. A mobilfejlesztés kontextusában a Load Test alkalmazható mind a szerveroldali (API, adatbázis, gyorsítótár), mind a kliens oldali (push értesítések feldolgozása, adatszinkronizáció) részre. A fő különbség a stressz-teszteléstől — a Load Test valós, nem extrém terhelést modellez. Az AWS Well-Architected Framework (2024) szerint a terheléses tesztelést valós használati analitikán alapuló terhelési profilokkal kell végezni.

A Load Test végezhető HTTP-kérések szintjén az API-hoz, WebSocket-kapcsolatok szintjén vagy adatbázis-tranzakciók szintjén. A cél — annak biztosítása, hogy az egyes kérések válaszideje ne haladja meg a meghatározott küszöbértéket (általában 500–1000 ms az API-knál), és az átviteli kapacitás (RPS — requests per second) megfeleljen a követelményeknek. A Google Cloud Armor (2024) percentiliseken alapuló küszöbértékeket határoz meg: a válaszidő p95-öse nem haladhatja meg a 2 másodpercet a kritikus végpontoknál.

A mobil backend terheléses tesztelése magában foglalja a tipikus forgatókönyvek szimulációját: regisztráció, hitelesítés, hírfolyam betöltése, űrlap elküldése. A forgatókönyvek HAR-fájlok (HTTP Archive) formájában kerülnek rögzítésre, és a terheléses tesztelő eszköz reprodukálja őket. A k6 dokumentációja (2025) szerint a HAR-konverzió 60%-kal csökkentheti a Load Test előkészítési idejét.

A terheléses tesztelés céljai

A Load Test első célja — a rendszer átviteli kapacitásának megerősítése. Ha a specifikáció 1000 RPS kezelését írja elő, a terheléses tesztnek ezt 20%-os tartalékkal kell megerősítenie. A Netflix Tech Blog (2024) szerint a Netflixnél a terheléses tesztelés 2x-es tartalékkal történik a csúcsterheléshez képest: ha 10000 RPS várható, a teszt 20000 RPS-t ellenőriz. Ez a megközelítés garantálja a stabilitást a hirtelen forgalmi kiugrásoknál.

A második cél — a szűk keresztmetszetek (bottleneckek) azonosítása az architektúrában. Tipikus szűk keresztmetszetek a mobil backendekben — adatbázis (lassú lekérdezések), gyorsítótár (hibás érvénytelenítési stratégia) és külső API-k (lassú harmadik féltől származó szolgáltatások). Distributed tracing (Jaeger, Zipkin) segít lokalizálni a problémát egy adott szolgáltatás vagy kérés szintjén.

A harmadik cél — a telítési pont meghatározása (saturation point). Ez az a pillanat, amikor az új felhasználók hozzáadása megszűnik növelni az átviteli kapacitást. Mobilalkalmazásokban a telítési pont gyakran az adatbázis-szerverek 70–80%-os CPU-terhelésénél következik be. Auto-scalingnek működésbe kell lépnie a pont elérése előtt.

Terheléses tesztelési forgatókönyvek

Csúcsterhelés (Spike Test) — hirtelen aktivitásnövekedés modellezése, például reggeli push-értesítések kiküldése vagy reklámkampány indítása. A Grafana k6 (2025) szerint a Spike Test a terhelés 100-ról 10000 RPS-re történő növekedését szimulálja 30 másodperc alatt. A rendszernek képesnek kell lennie kezelni a kérések elvesztése nélkül és anélkül, hogy a válaszidő 50%-nál többel nőne.

Állandó terhelés (Endurance Test) — a rendszer stabilitásának ellenőrzése hosszú távú terhelés alatt. Tipikus időtartam — 1–4 óra. Az Endurance Test feltárja a memóriaszivárgásokat a szerveralkalmazásokban, az adatbázis-kapcsolati pool problémáit és a gyorsítótár teljesítményének romlását. A PostgreSQL kapcsolati poolja hosszú terhelés alatt, helyes konfiguráció nélkül 2–3 óra működés után kimerítheti a rendelkezésre álló kapcsolatokat.

Lépcsős terhelés (Step Load Test) — a terhelés fokozatos növelése 10–20%-os lépésekben 2–5 percenként. Ez a forgatókönyv segít megtalálni azt a pontos határt, ahol a rendszer romlani kezd. InfluxDB és Prometheus gyűjti a mérőszámokat minden lépésnél a válaszidő RPS-től való függésének grafikonjának felépítéséhez.

Load Test mérőszámok

Válaszidő

Válaszidő (Response Time) — a Load Test fő mérőszáma. Ezredmásodpercben mérjük, és percentilisek alapján elemezzük: p50 (medián), p95 és p99. A Google SRE (2024) a p95-ös küszöbértéket legfeljebb 1000 ms-ban javasolja REST API-knál és legfeljebb 200 ms-ban gRPC-nél. A percentilisek fontosabbak az átlagnál, mert a legrosszabb kérések viselkedését mutatják, amelyeket a felhasználók először észrevesznek. Apdex (Application Performance Index) — összetett mérőszám, amely figyelembe veszi az elégedett, tűrő és csalódott felhasználók arányát.

Átviteli kapacitás

Átviteli kapacitás (Throughput) — a sikeres kérések száma időegységenként. RPS-ben (requests per second) vagy TPS-ben (transactions per second) mérjük. A Throughput grafikonja „idő — RPS” koordinátákban lineárisnak kell lennie a telítési pontig. A Throughput hirtelen csökkenése a terhelés növekedésekor — a rendszer határának elérését jelzi. Apache Bench és wrk — egyszerű CLI-eszközök a Throughput gyors ellenőrzéséhez a fejlesztési szakaszban.

Hibaszázalék

Hibaszázalék (Error Rate) — a 4xx vagy 5xx HTTP-státuszú válaszok aránya a kérések teljes számához viszonyítva. Megengedett küszöbérték — kevesebb, mint 1%. A 429-es (Too Many Requests) és 503-as (Service Unavailable) hibák magas terhelés alatt a rate limiting és auto-scaling konfigurálásának szükségességét jelzik. Az API Gateway oldalán lévő Rate limiter védi a backendet a megengedett terhelés túllépésétől. Retry policy exponenciális visszahúzódással segíti a klienseket az ideiglenes hibák helyes kezelésében.

Eszközök a Load Test-hez

k6 (Grafana)

k6 — a vezető Open Source eszköz terheléses teszteléshez a Grafana-tól. A szkriptek JavaScript-ben íródnak, támogatják a moduláris forgatókönyveket, küszöbértékeket (thresholds) és integrációt a Prometheus-szal és InfluxDB-vel. A k6 futtatható CLI-ben és a Grafana Cloud k6 felhőben is. Grafana Cloud automatikusan épít irányítópultokat a Load Test eredményei alapján, és összehasonlítja azokat a historikus adatokkal. A k6 támogatja a Protocol Buffers-t és a gRPC-t a k6/net/grpc külön modulon keresztül.

Apache JMeter

Apache JMeter — klasszikus eszköz Load Test-hez grafikus felülettel. Széles protokollválasztékot támogat: HTTP, JDBC, JMS, FTP és TCP. A JMeter jobban alkalmas összetett forgatókönyvekhez, sok különböző típusú kéréssel, de több manuális konfigurációt igényel a k6-hoz képest. JMeter Plugins bővíti a funkcionalitást WebSocket és gRPC teszteléshez. Elosztott futtatáshoz a JMeter master-slave architektúrát használ egy vezérlővel.

Locust

Locust — Python-alapú eszköz, amely lehetővé teszi a terhelési forgatókönyvek kódban történő leírását. A Locust kényelmes azoknak a csapatoknak, amelyek a Python-t használják fő automatizálási nyelvként. A k6-tól és JMeter-től eltérően a Locust beépítve támogatja az elosztott futtatást: egy master-csomópont koordinál több worker-csomópontot. Elosztott futtatás lehetővé teszi akár 100000 RPS terhelés generálását több gépről. A Locust WebSocket-tesztelést is támogat egyéni bővítményeken keresztül.

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élda Load Test írására k6-ban

A fenti k6 szkript bemutatja a terheléses teszt tipikus struktúráját. Az Options határozza meg a terhelési profilt: 2 perces ramp-up 100 felhasználóig, majd 5 perc állandó terhelés és ismételt ramp-up 200 felhasználóig. Thresholds határozza meg a teszt sikeres teljesítésének kritériumait: a kérési idő p95-öse legfeljebb 500 ms, a hibaszázalék kevesebb, mint 1%. Ha a küszöbértékek túllépésre kerülnek, a k6 nem nulla kóddal fejezi be a tesztet — ez lehetővé teszi a Load Test CI/CD-be történő integrálását.

A mobilfejlesztésben a szerveroldali Load Test különösen fontos új funkciók indításakor, amelyek további terhelést hoznak létre: like-ok, kommentek, streaming. Javaslat — végezzen Load Test-et minden staging-en a production-be való kivezetés előtt. Az alap terhelési profil létrehozása az API tervezési szakaszában segít elkerülni az architekturális problémákat a későbbi fázisokban.