Load Test у мобилном развоју — шта је, сценарији и како се изводи

Шта је Load Test?

Load Test (тестирање оптерећења) — је процес провере како систем ради под очекиваним бројем истовремених захтева или корисника. У контексту развоја мобилних апликација, Load Test се примењује како на серверски део (API, база података, кеш), тако и на клијентски (обрада push обавештења, синхронизација података). Главна разлика у односу на стрес тестирање је што Load Test моделира реално, а не екстремно оптерећење. Према AWS Well-Architected Framework (2024), тестирање оптерећења треба да се спроводи коришћењем профила оптерећења заснованих на реалној аналици коришћења.

Load Test се може спроводити на нивоу HTTP захтева ка API-ју, на нивоу WebSocket веза или на нивоу транзакција базе података. Циљ је да се осигура да време одговора сваког захтева не прелази постављени праг (обично 500–1000 ms за API), а проток (RPS — број захтева у секунди) одговара захтевима. Google Cloud Armor (2024) дефинише граничне вредности на основу перцентила: p95 времена одговора не треба да прелази 2 секунде за критичне ендпоинте.

Тестирање оптерећења мобилног бекенда укључује симулацију типичних сценарија: регистрација, ауторизација, учитавање феда, слање формулара. Сценарији се чувају у облику HAR (датотека HTTP Archive) и репродукују се алатом за тестирање оптерећења. Према k6 документацији (2025), HAR конверзија омогућава скраћење времена припреме Load Testа за 60%.

Циљеви тестирања оптерећења

Први циљ Load Testа је потврда протока система. Ако спецификација захтева обраду 1000 RPS, тест оптерећења мора да то потврди са 20% маргином. Према Netflix Tech Blog (2024), тестирање оптерећења у Netflix-у се спроводи са 2x маргином од пикног оптерећења: ако се очекује 10000 RPS, тест проверава 20000 RPS. Овакав приступ гарантује стабилност при изненадним скоковима саобраћаја промета.

Други циљ је откривање уских грла (bottlenecks) у архитектури. Типичне уске грле у мобилним бекендовима — база података (спори упити), кеш (неисправна стратегија инвалидације) и спољашњи API-ји (споре услуге трећих страна). Distributed tracing (Jaeger, Zipkin) помаже да локализујете проблем на нивоу одређене услуге или захтева.

Трећи циљ је одређивање тачке засићења (saturation point). То је тренутак када додавање нових корисника престаје да повећава проток. У мобилним апликацијама, тачка засићења често наступа при 70–80% оптерећења CPU-а на серверима базе података. Auto-scaling треба да се активира пре достизања ове тачке.

Сценарији тестирања оптерећења

Пикно оптерећење (Spike Test) — моделира нагли скок активности, на примјер јутарње слање push обавештења или покретање рекламне кампање. Према Grafana k6 (2025), Spike Test симулира пораст оптерећења са 100 на 10000 RPS у 30 секунди. Систем мора да издржи без губитка захтева и без прекорачивања времена одговора за више од 50%.

Континуирано оптерећење (Endurance Test) — провера стабилности система при дуготрајном раду под оптерећењем. Типично трајање — 1–4 сата. Endurance Test открива цурење меморије у серверским апликацијама, проблеме са пулом веза ка бази података и деградацију перформанси кеша. Пул веза PostgreSQL-а при дуготрајном оптерећење без исправне конфигурације може да исцрпи доступне везе након 2–3 сата рада.

Степенично оптерећење (Step Load Test) — постепно повећање оптерећења са кораком од 10–20% сваких 2–5 минута. Овај сценариј помаже да се пронаће тачна граница након које систем деградира. InfluxDB и Prometheus прикупљају метрике на сваком кораку за изградњу графика зависности времена одговора од RPS-а.

Метрике Load Testа

Време одговора

Време одговора (Response Time) — основна метрика Load Testа. Мјери се у милисекундама и анализира по перцентилима: p50 (медијан), p95 и p99. Google SRE (2024) препоручује праг p95 не више од 1000 ms за REST API и не више од 200 ms за gRPC. Перцентили су важнији од просека јер показују понашање најгорих захтева које корисници први примећују. Apdex (Application Performance Index) — сложена метрика која узима у обзир удео задовољних, толерантних и фрустрираних корисника.

Проток

Проток (Throughput) — број успешних захтева у јединици времена. Мјери се у RPS-у (број захтева у секунди) или TPS-у (број транзакција у секунди). График протока у координатама “време — RPS” треба да буде линеаран до тачке засићења. Нагли пад протока при повећању оптерећења — знак да је систем достигао границу. Apache Bench и wrk — једноставни CLI алати за брзу проверу протока у фази развоја.

Проценат грешака

Проценат грешака (Error Rate) — удео одговора са HTTP статусом 4xx или 5xx у укупном броју захтева. Дозвољени праг — мање од 1%. Грешке 429 (Too Many Requests) и 503 (Service Unavailable) при високом оптерећењу указују на потребу за конфигурацијом rate limiting-а и auto-scaling-а. Rate limiter на страни API Gateway-а штити бекенд од прекорачивања дозвољеног оптерећења. Retry policy са exponential backoff-ом помаже клијентима да исправно обрађе привремене грешке.

Алати за Load Test

k6 (Grafana)

k6 — водећи Open Source алат за тестирање оптерећења од Grafane. Скрипте се пишу у JavaScript-у, подржавају се модулни сценарији, прагови (thresholds) и интеграција са Prometheus и InfluxDB. k6 се може покретати и у CLI-ју и у облаку Grafana Cloud k6. Grafana Cloud аутоматски гради контролне табле на основу резултата Load Testа и упоређује их са историјским подацима. k6 подржава Protocol Buffers и gRPC путем засебног модула k6/net/grpc.

Apache JMeter

Apache JMeter — класични алат за Load Test са графичким интерфејсом. Подржава широк опсег протокола: HTTP, JDBC, JMS, FTP и TCP. JMeter је погоднији за сложене сценарије са више различитих врста захтева, али захтева више ручног подешавања у поређењу са k6. JMeter Plugins проширују функционалност за тестирање WebSocket-а и gRPC-а. За дистрибуирано покретање, JMeter користи master-slave архитектуру са једним контролером.

Locust

Locust — алат заснован на Python-у који омогућава описивање сценарија оптерећења у коду. Locust је згодан за тимове који користе Python као главни језик за аутоматизацију. За разлику од k6 и JMeter-а, Locust из кутије подржава дистрибуирано покретање: један master чвор координира више worker чворова. Дистрибуирано покретање омогућава генерисање оптерећења до 100000 RPS са више машина. Locust такође подржава тестирање WebSocket-а путем прилагођених проширења.

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

Примјер писања Load Testа у k6

Горнји k6 скрипт приказује типичну структуру теста оптерећења. Options дефинише профил оптерећења: ramp-up од 2 минута до 100 корисника, затим 5 минута континуираног оптерећења и поновни ramp-up до 200 корисника. Thresholds постављају критеријуме за пролаз теста: p95 времена захтева не више од 500 ms, проценат грешака мањи од 1%. Ако се прагови прекораче, k6 завршава тест са ненултим кодом — то омогућава уграђивање Load Testа у CI/CD.

У развоју мобилних апликација, Load Test серверског дела је посебно важан при покретању нових функција које стварају додатно оптерећење: лајкови, коментари, стриминг. Препорука — спроводите Load Test на сваком staging-у пре избацивања у производњу. Креирање базног профила оптерећења у фази дизајна API-ја помаже да се избегну архитектурни проблеми у каснијим фазама.