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

Какво е Load Test?

Load Test (натоварващо тестване) — това е процес на проверка как системата работи при очаквания брой едновременни заявки или потребители. В контекста на мобилната разработка Load Test се прилага както към сървърната част (API, база данни, кеш), така и към клиентската (обработка на push известия, синхронизация на данни). Основната разлика от стрес тестването — Load Test моделира реално, а не екстремно натоварване. Според AWS Well-Architected Framework (2024), натоварващото тестване трябва да се провежда с профили на натоварване, основани на реална аналитика на използването.

Load Test може да се провежда на ниво HTTP заявки към API, на ниво WebSocket връзки или на ниво транзакции в базата данни. Целта — да се уверим, че времето за отговор на всяка заявка не надвишава зададения праг (обикновено 500–1000 мс за API), а пропускателната способност (RPS — requests per second) съответства на изискванията. Google Cloud Armor (2024) определя праговите стойности на база персентили: p95 на времето за отговор не трябва да надвишава 2 секунди за критичните ендпойнти.

Натоварващото тестване на мобилния бекенд включва симулация на типични сценарии: регистрация, авторизация, зареждане на емисията, изпращане на формуляр. Сценариите се записват под формата на HAR файлове (HTTP Archive) и се възпроизвеждат от инструмента за натоварващо тестване. Според k6 documentation (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 мс за REST API и не повече от 200 мс за gRPC. Персентилите са по-важни от средната стойност, защото показват поведението на най-лошите заявки, които потребителите забелязват първи. Apdex (Application Performance Index) — съставна метрика, която отчита дела на удовлетворените, толерантните и разочарованите потребители.

Пропускателна способност

Пропускателната способност (Throughput) — броят успешни заявки за единица време. Измерва се в RPS (requests per second) или TPS (transactions per second). Графиката на Throughput в координати „време — RPS" трябва да бъде линейна до точката на насищане. Рязък спад на Throughput при увеличаване на натоварването — признак за достигане на предела на системата. Apache Bench и wrk — прости CLI инструменти за бърза проверка на Throughput на етапа на разработка.

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

Процентът на грешките (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 инструмент за натоварващо тестване от Grafana. Скриптовете се пишат на 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 мс, процент на грешките по-малко от 1%. Ако праговете бъдат превишени, k6 завършва теста с ненулев код — това позволява Load Test да бъде вграден в CI/CD.

В мобилната разработка Load Test на сървърната част е особено важен при пускането на нови функционалности, които създават допълнително натоварване: лайкове, коментари, стрийминг. Препоръка — провеждайте Load Test на всеки staging преди пускане в production. Създаването на baseline профил на натоварване на етапа на проектиране на API помага да се избегнат архитектурни проблеми на по-късни етапи.