Load Test în dezvoltarea aplicațiilor mobile — ce este, scenarii și cum se efectuează

Ce este Load Test?

Load Test (testarea de încărcare) — este procesul de verificare a modului în care sistemul funcționează sub numărul așteptat de cereri sau utilizatori simultani. În contextul dezvoltării aplicațiilor mobile, Load Test se aplică atât părții de server (API, bază de date, cache), cât și părții client (procesarea notificărilor push, sincronizarea datelor). Principala diferență față de testarea de stres este că Load Test modelează încărcarea reală, nu cea extremă. Conform AWS Well-Architected Framework (2024), testarea de încărcare ar trebui efectuată folosind profile de încărcare bazate pe analitica reală de utilizare.

Load Test poate fi efectuat la nivelul cererilor HTTP către API, la nivelul conexiunilor WebSocket sau la nivelul tranzacțiilor bazei de date. Scopul este de a se asigura că timpul de răspuns al fiecărei cereri nu depășește pragul stabilit (de obicei 500–1000 ms pentru API), iar capacitatea de transfer (RPS — cereri pe secundă) corespunde cerințelor. Google Cloud Armor (2024) definește valorile de prag pe baza percentilelor: p95 al timpului de răspuns nu trebuie să depășească 2 secunde pentru endpoint-urile critice.

Testarea de încărcare a backend-ului mobil include simularea scenariilor tipice: înregistrare, autorizare, încărcarea fluxului, trimiterea formularului. Scenariile sunt salvate sub formă de fișiere HAR (HTTP Archive) și sunt redate de instrumentul de testare a încărcării. Conform documentației k6 (2025), conversia HAR permite reducerea timpului de pregătire a Load Test cu 60%.

Obiectivele testării de încărcare

Primul obiectiv al Load Test este confirmarea capacității de transfer a sistemului. Dacă specificația necesită procesarea a 1000 RPS, testul de încărcare trebuie să confirme acest lucru cu o marjă de 20%. Conform Netflix Tech Blog (2024), testarea de încărcare la Netflix se efectuează cu o marjă de 2x față de încărcarea de vârf: dacă se așteaptă 10000 RPS, testul verifică 20000 RPS. Această abordare garantează stabilitatea la creșteri bruște de trafic.

Al doilea obiectiv este identificarea blocajelor (bottlenecks) în arhitectură. Blocajele tipice în backend-urile mobile — baza de date (interogări lente), cache (strategie incorectă de invalidare) și API-uri externe (servicii terțe lente). Distributed tracing (Jaeger, Zipkin) ajută la localizarea problemei la nivelul unui serviciu sau cereri specifice.

Al treilea obiectiv este determinarea punctului de saturație (saturation point). Acesta este momentul în care adăugarea de noi utilizatori nu mai crește capacitatea de transfer. În aplicațiile mobile, punctul de saturație apare adesea la 70–80% încărcare CPU pe serverele bazei de date. Auto-scaling trebuie să se activeze înainte de atingerea acestui punct.

Scenariile testării de încărcare

Încărcarea de vârf (Spike Test) — modelează o creștere bruscă a activității, de exemplu trimiterea de dimineață a notificărilor push sau lansarea unei campanii publicitare. Conform Grafana k6 (2025), Spike Test simulează creșterea încărcării de la 100 la 10000 RPS în 30 de secunde. Sistemul trebuie să facă față fără pierderea cererilor și fără depășirea timpului de răspuns cu mai mult de 50%.

Încărcarea constantă (Endurance Test) — verificarea stabilității sistemului în timpul funcționării prelungite sub sarcină. Durata tipică — 1–4 ore. Endurance Test detectează scurgerile de memorie în aplicațiile server, problemele cu pool-ul de conexiuni la baza de date și degradarea performanței cache-ului. Pool-ul de conexiuni PostgreSQL la sarcină prelungită fără o configurare corectă poate epuiza conexiunile disponibile după 2–3 ore de funcționare.

Încărcarea treptată (Step Load Test) — creșterea treptată a încărcării cu un pas de 10–20% la fiecare 2–5 minute. Acest scenariu ajută la găsirea limitei exacte după care sistemul degradează. InfluxDB și Prometheus colectează metrici la fiecare pas pentru construirea graficului de dependență a timpului de răspuns de RPS.

Metricile Load Test

Timpul de răspuns

Timpul de răspuns (Response Time) — metrica principală a Load Test. Se măsoară în milisecunde și se analizează după percentile: p50 (mediană), p95 și p99. Google SRE (2024) recomandă pragul p95 de cel mult 1000 ms pentru REST API și de cel mult 200 ms pentru gRPC. Percentilele sunt mai importante decât media, deoarece arată comportamentul celor mai proaste cereri, pe care utilizatorii le observă în primul rând. Apdex (Application Performance Index) — o metrică compozită care ia în considerare proporțiile utilizatorilor mulțumiți, toleranți și frustrați.

Capacitatea de transfer

Capacitatea de transfer (Throughput) — numărul de cereri reușite pe unitatea de timp. Se măsoară în RPS (cereri pe secundă) sau TPS (tranzacții pe secundă). Graficul capacității de transfer în coordonatele „timp — RPS” trebuie să fie liniar până la punctul de saturație. O scădere bruscă a capacității de transfer la creșterea încărcării — semn al atingerii limitei sistemului. Apache Bench și wrk — instrumente CLI simple pentru verificarea rapidă a capacității de transfer în faza de dezvoltare.

Procentul de erori

Procentul de erori (Error Rate) — proporția răspunsurilor cu cod HTTP 4xx sau 5xx din numărul total de cereri. Pragul admisibil — sub 1%. Erorile 429 (Too Many Requests) și 503 (Service Unavailable) la încărcare mare indică necesitatea configurării rate limiting și auto-scaling. Rate limiter-ul de pe partea API Gateway protejează backend-ul de depășirea încărcării admisibile. Retry policy cu exponential backoff ajută clienții să gestioneze corect erorile temporare.

Instrumente pentru Load Test

k6 (Grafana)

k6 — instrumentul Open Source lider pentru testarea de încărcare de la Grafana. Scripturile se scriu în JavaScript, sunt acceptate scenarii modulare, praguri (thresholds) și integrarea cu Prometheus și InfluxDB. k6 poate fi rulat atât în CLI, cât și în cloud Grafana Cloud k6. Grafana Cloud construiește automat dashboard-uri pe baza rezultatelor Load Test și le compară cu datele istorice. k6 acceptă Protocol Buffers și gRPC prin intermediul modulului separat k6/net/grpc.

Apache JMeter

Apache JMeter — instrumentul clasic pentru Load Test cu interfață grafică. Suportă o gamă largă de protocoale: HTTP, JDBC, JMS, FTP și TCP. JMeter este mai potrivit pentru scenarii complexe cu mai multe tipuri diferite de cereri, dar necesită mai multă configurare manuală în comparație cu k6. JMeter Plugins extind funcționalitatea pentru testarea WebSocket și gRPC. Pentru rularea distribuită, JMeter folosește arhitectura master-slave cu un singur controler.

Locust

Locust — instrument în Python care permite descrierea scenariilor de încărcare în cod. Locust este convenabil pentru echipele care folosesc Python ca limbaj principal pentru automatizare. Spre deosebire de k6 și JMeter, Locust acceptă rularea distribuită din cutie: un nod master coordonează mai multe noduri worker. Rularea distribuită permite generarea de încărcare de până la 100000 RPS de pe mai multe mașini. Locust acceptă, de asemenea, testarea WebSocket prin extensii personalizate.

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

Exemplu de scriere a unui Load Test în k6

Scriptul k6 de mai sus demonstrează structura tipică a unui test de încărcare. Options definește profilul de încărcare: ramp-up de 2 minute până la 100 de utilizatori, apoi 5 minute de încărcare constantă și din nou ramp-up până la 200 de utilizatori. Thresholds definesc criteriile de promovare a testului: p95 al timpului cererii de cel mult 500 ms, procentul de erori sub 1%. Dacă pragurile sunt depășite, k6 încheie testul cu un cod nenul — acest lucru permite integrarea Load Test în CI/CD.

În dezvoltarea aplicațiilor mobile, Load Test al părții de server este deosebit de important la lansarea de noi funcții care generează încărcare suplimentară: aprecieri, comentarii, streaming. Recomandare — efectuați Load Test pe fiecare staging înainte de implementarea în producție. Crearea unui profil de încărcare de bază în faza de proiectare a API-ului ajută la evitarea problemelor arhitecturale în etapele ulterioare.