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 помогает избежать архитектурных проблем на поздних стадиях.