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 — запитів на секунду) відповідає вимогам. 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 мс для REST API та не більше 200 мс для gRPC. Перцентилі важливіші за середні значення, оскільки вони показують поведінку найгірших запитів, які користувачі помічають найперше. Apdex (Індекс продуктивності додатків) — це складена метрика, яка враховує частку задоволених, терпимих та розчарованих користувачів.

Пропускна здатність

Пропускна здатність (Throughput) — кількість успішних запитів за одиницю часу. Вимірюється в RPS (запитів на секунду) або TPS (транзакцій на секунду). Графік 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 захищає бекенд від перевищення допустимого навантаження. Політика повторних спроб з 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 розширюють функціонал для тестування 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. Створення базового профілю навантаження на етапі проєктування API допомагає уникнути архітектурних проблем на пізніх стадіях.