Load Test in mobiele ontwikkeling — wat het is, scenario's en hoe het wordt uitgevoerd

Wat is Load Test?

Load Test (belastingtesten) — is het proces van het controleren hoe het systeem werkt onder het verwachte aantal gelijktijdige verzoeken of gebruikers. In de context van mobiele ontwikkeling wordt Load Test zowel toegepast op het servergedeelte (API, database, cache) als op de client (verwerking van pushmeldingen, gegevenssynchronisatie). Het belangrijkste verschil met stresstesten is dat Load Test de werkelijke, niet extreme belasting modelleert. Volgens AWS Well-Architected Framework (2024) moet belastingtesten worden uitgevoerd met behulp van belastingprofielen op basis van werkelijke gebruiksanalyses.

Load Test kan worden uitgevoerd op het niveau van HTTP-verzoeken naar de API, op het niveau van WebSocket-verbindingen of op het niveau van databasetransacties. Doel — ervoor zorgen dat de responstijd van elk verzoek de vastgestelde drempel (meestal 500–1000 ms voor API) niet overschrijdt en dat de doorvoer (RPS — verzoeken per seconde) voldoet aan de vereisten. Google Cloud Armor (2024) bepaalt drempelwaarden op basis van percentielen: p95 van de responstijd mag niet meer dan 2 seconden bedragen voor kritieke endpoints.

Belastingtesten van mobiele backend omvat simulatie van typische scenario’s: registratie, autorisatie, laden van de feed, verzenden van formulieren. Scenario’s worden opgeslagen als HAR-bestanden (HTTP Archive) en afgespeeld door de belastingtesttool. Volgens k6-documentatie (2025) kan HAR-conversie de voorbereidingstijd van Load Test met 60% verminderen.

Doelen van belastingtesten

Het eerste doel van Load Test is bevestiging van de doorvoer van het systeem. Als de specificatie verwerking van 1000 RPS vereist, moet de belastingtest dit bevestigen met een marge van 20%. Volgens Netflix Tech Blog (2024) wordt belastingtesten bij Netflix uitgevoerd met een marge van 2x ten opzichte van de piekbelasting: als 10000 RPS wordt verwacht, test men 20000 RPS. Deze aanpak garandeert stabiliteit bij plotselinge pieken in het verkeer.

Het tweede doel is identificatie van knelpunten (bottlenecks) in de architectuur. Typische knelpunten in mobiele backends — database (trage queries), cache (verkeerde invalidatiestrategie) en externe API’s (trage diensten van derden). Distributed tracing (Jaeger, Zipkin) helpt het probleem te lokaliseren op het niveau van een specifieke service of verzoek.

Het derde doel is bepaling van het verzadigingspunt (saturation point). Dit is het moment waarop het toevoegen van nieuwe gebruikers de doorvoer niet meer verhoogt. In mobiele applicaties treedt het verzadigingspunt vaak op bij 70–80% CPU-belasting op databaseservers. Auto-scaling moet worden geactiveerd voordat dit punt wordt bereikt.

Scenario’s van belastingtesten

Piekbelasting (Spike Test) — modelleert een plotselinge activiteitspiek, bijvoorbeeld het ochtendlijke verzenden van pushmeldingen of de start van een reclamecampagne. Volgens Grafana k6 (2025) simuleert Spike Test een belastingstoename van 100 naar 10000 RPS in 30 seconden. Het systeem moet dit aankunnen zonder verlies van verzoeken en zonder de responstijd met meer dan 50% te overschrijden.

Constante belasting (Endurance Test) — controle van de systeemstabiliteit bij langdurige belasting. Typische duur — 1–4 uur. Endurance Test detecteert geheugenlekken in serverapplicaties, problemen met de databaseverbindingspool en prestatievermindering van de cache. Verbindingspool van PostgreSQL kan bij langdurige belasting zonder juiste configuratie de beschikbare verbindingen na 2–3 uur uitputten.

Stapsgewijze belasting (Step Load Test) — geleidelijke toename van de belasting met stappen van 10–20% elke 2–5 minuten. Dit scenario helpt de exacte grens te vinden waarna het systeem degradeert. InfluxDB en Prometheus verzamelen bij elke stap metrics voor het bouwen van de grafiek van de afhankelijkheid van responstijd van RPS.

Metrics van Load Test

Responstijd

Responstijd (Response Time) — de belangrijkste metric van Load Test. Gemeten in milliseconden en geanalyseerd op percentielen: p50 (mediaan), p95 en p99. Google SRE (2024) beveelt een p95-drempel aan van niet meer dan 1000 ms voor REST API en niet meer dan 200 ms voor gRPC. Percentielen zijn belangrijker dan het gemiddelde omdat ze het gedrag van de slechtste verzoeken tonen die gebruikers het eerst opmerken. Apdex (Application Performance Index) — een samengestelde metric die rekening houdt met de aandelen tevreden, tolerante en gefrustreerde gebruikers.

Doorvoer

Doorvoer (Throughput) — aantal succesvolle verzoeken per tijdseenheid. Gemeten in RPS (verzoeken per seconde) of TPS (transacties per seconde). De doorvoergrafiek in coördinaten “tijd — RPS” moet lineair zijn tot het verzadigingspunt. Een plotselinge daling van de doorvoer bij toename van de belasting is een teken dat de systeemgrens is bereikt. Apache Bench en wrk — eenvoudige CLI-tools voor snelle controle van de doorvoer in de ontwikkelfase.

Foutpercentage

Foutpercentage (Error Rate) — aandeel antwoorden met HTTP-status 4xx of 5xx van het totale aantal verzoeken. Toegestane drempel — minder dan 1%. Fouten 429 (Too Many Requests) en 503 (Service Unavailable) bij hoge belasting wijzen op de noodzaak van configuratie van rate limiting en auto-scaling. Rate limiter aan de kant van API Gateway beschermt de backend tegen overschrijding van de toegestane belasting. Retry policy met exponential backoff helpt clients tijdelijke fouten correct af te handelen.

Tools voor Load Test

k6 (Grafana)

k6 — de toonaangevende Open Source tool voor belastingtesten van Grafana. Scripts worden geschreven in JavaScript, modulaire scenario’s, drempels (thresholds) en integratie met Prometheus en InfluxDB worden ondersteund. k6 kan zowel in CLI als in de cloud Grafana Cloud k6 worden uitgevoerd. Grafana Cloud bouwt automatisch dashboards op basis van Load Test-resultaten en vergelijkt ze met historische gegevens. k6 ondersteunt Protocol Buffers en gRPC via de aparte module k6/net/grpc.

Apache JMeter

Apache JMeter — de klassieke tool voor Load Test met grafische interface. Ondersteunt een breed scala aan protocollen: HTTP, JDBC, JMS, FTP en TCP. JMeter is meer geschikt voor complexe scenario’s met meerdere verschillende soorten verzoeken, maar vereist meer handmatige configuratie in vergelijking met k6. JMeter Plugins breiden de functionaliteit uit voor het testen van WebSocket en gRPC. Voor gedistribueerde uitvoering gebruikt JMeter een master-slave architectuur met één controller.

Locust

Locust — een tool in Python waarmee belastingscenario’s in code kunnen worden beschreven. Locust is handig voor teams die Python als primaire taal voor automatisering gebruiken. In tegenstelling tot k6 en JMeter ondersteunt Locust direct gedistribueerde uitvoering: één master-node coördineert meerdere worker-nodes. Gedistribueerde uitvoering maakt het mogelijk belasting tot 100000 RPS te genereren vanaf meerdere machines. Locust ondersteunt ook WebSocket-testen via aangepaste extensies.

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)
}

Voorbeeld van het schrijven van een Load Test in k6

Het bovenstaande k6-script demonstreert de typische structuur van een belastingtest. Options definieert het belastingprofiel: ramp-up van 2 minuten naar 100 gebruikers, daarna 5 minuten constante belasting en opnieuw ramp-up naar 200 gebruikers. Thresholds bepalen de criteria voor het slagen van de test: p95 van de verzoekstijd niet meer dan 500 ms, foutpercentage minder dan 1%. Als drempels worden overschreden, beëindigt k6 de test met een niet-nul code — dit maakt integratie van Load Test in CI/CD mogelijk.

In mobiele ontwikkeling is Load Test van het servergedeelte vooral belangrijk bij het lanceren van nieuwe functies die extra belasting creëren: likes, reacties, streaming. Aanbeveling — voer Load Test uit op elke staging voor implementatie in productie. Het maken van een basisbelastingprofiel in de ontwerpfase van de API helpt architectuurproblemen in latere stadia te voorkomen.