Представьте: ваше мобильное приложение выходит в топ App Store, за ночь приходит 50 000 новых пользователей. Утром вы видите даунтайм бэкенда — ошибки 504 на всех экранах. Без нагрузочного тестирования бэкенд не выдержит пиковых всплесков от push-уведомлений или рекламной кампании. Мы проводим полный цикл тестирования: пишем сценарии на k6, JMeter или Gatling, настраиваем профили нагрузки, анализируем узкие места и даём рекомендации по оптимизации. k6 в 3 раза быстрее запускает сценарии по сравнению с JMeter на больших объёмах, а его сценарии компактны и легко читаются. Ниже разберём процесс на примере типичного мобильного API.
Почему нагрузочное тестирование API критично для мобильного приложения?
Мобильный трафик отличается от веба: устройства отправляют множество одновременных запросов, работают в фоновом режиме, используют непредсказуемые сетевые условия. Без профилирования нагрузки бэкенд может не выдержать пиковых нагрузок. Типичная проблема — бэкенд рассчитан на среднюю нагрузку, а не на пиковые всплески от push-уведомлений или рекламной кампании.
Как мы выбираем инструмент?
Три основных инструмента, каждый под свою задачу:
| Инструмент | Язык сценариев | Сильная сторона |
|---|---|---|
| k6 | JavaScript | Современный, CI-friendly, низкий порог входа |
| JMeter | XML / GUI | Зрелый, богатые плагины, visual тест-дизайн |
| Gatling | Scala / DSL | Точные метрики, удобные HTML-отчёты |
Для большинства мобильных API выбираем k6 — компактные сценарии, нативная интеграция с Grafana, запуск в Docker без JVM. Специалисты с опытом 5+ лет настраивают инструмент под вашу архитектуру.
Написание k6-сценария для мобильного API
Типичный мобильный API имеет особенности: JWT-авторизация с коротким TTL, refresh-токены, gzip-сжатие ответов, иногда GraphQL вместо REST. Сценарий должен это учитывать.
import http from 'k6/http';
import { check, sleep } from 'k6';
import { SharedArray } from 'k6/data';
// Тестовые аккаунты из CSV — не один аккаунт для всех VU
const users = new SharedArray('users', () => open('./test_users.csv').split('\n').map(line => {
const [email, password] = line.split(',');
return { email, password };
}));
export const options = {
stages: [
{ duration: '2m', target: 100 }, // разгон
{ duration: '5m', target: 500 }, // плато
{ duration: '2m', target: 1000 }, // пик
{ duration: '1m', target: 0 }, // спад
],
thresholds: {
http_req_duration: ['p(95)<500'], // 95% запросов < 500ms
http_req_failed: ['rate<0.01'], // менее 1% ошибок
},
};
export default function () {
const user = users[__VU % users.length];
// Логин + получение токена
const loginRes = http.post('https://api.example.com/v1/auth/login', JSON.stringify({
email: user.email,
password: user.password,
}), {
headers: { 'Content-Type': 'application/json' },
});
check(loginRes, {
'login 200': (r) => r.status === 200,
'has token': (r) => r.json('data.access_token') !== undefined,
});
const token = loginRes.json('data.access_token');
sleep(1); // имитируем поведение пользователя
// Загрузка ленты
const feedRes = http.get('https://api.example.com/v1/feed?page=1&limit=20', {
headers: { Authorization: `Bearer ${token}` },
});
check(feedRes, {
'feed 200': (r) => r.status === 200,
'feed has items': (r) => r.json('data.items').length > 0,
});
sleep(2);
}
Официальная документация k6 рекомендует использовать SharedArray для распределения тестовых данных между виртуальными пользователями.
SharedArray для пользователей — критично. Если все Virtual Users используют один аккаунт, бэкенд может кэшировать сессию и результаты будут некорректными.
Какие профили нагрузки нужны?
Мобильный трафик неравномерен. Мы определяем четыре типичных профиля:
Подробнее о профилях нагрузки
| Профиль | Цель | Длительность | Критерий успеха |
|---|---|---|---|
| Базовый | Стабильная работа 24/7 | 1–2 часа | p95 < 300 ms, error rate < 0.1% |
| Пиковый | Утренний/вечерний всплеск | 30 минут | p95 < 500 ms, error rate < 1% |
| Стресс-тест | Поиск точки отказа | 10–20 минут | error rate < 5% |
| Soak-тест | Выявление утечек | 4–8 часов | latency не растёт |
Базовый — стабильная нагрузка 24/7. Проверяем, что при среднем трафике p95 < 300 ms.
Пиковый — утренний и вечерний всплеск. Ступенчатый рост от 10% до 300% среднего за 5 минут.
Стресс-тест — намеренно превышаем расчётный максимум, ищем точку отказа. До тех пор, пока error rate не превысит 5% или latency не вырастет в 10 раз.
Soak-тест — 70% от пикового в течение 4–8 часов. Ловит утечки памяти на бэкенде, переполнение пула соединений к БД, ротацию логов.
Анализ результатов: что искать в метриках
k6 отправляет метрики в Grafana через InfluxDB или встроенный Prometheus remote write:
k6 run --out influxdb=http://localhost:8086/k6 scenario.js
После прогона смотрим на:
-
http_req_durationпо перцентилям (p50, p90, p95, p99) -
http_req_blocked— время в очереди (высокое значение = connection pool исчерпан) -
http_req_connecting— время установки TCP-соединения (высокое = нет keep-alive) -
data_received— объём данных (неожиданно большой = нет gzip или лишние поля в ответе)
Типичные узкие места в мобильном API:
- N+1 запросы к БД при загрузке ленты с вложенными объектами
- Отсутствие индекса на
user_id+created_atв таблице постов - Синхронная отправка push-уведомлений в теле запроса вместо фоновой очереди
Запуск в CI
- name: Run k6 load test
uses: grafana/[email protected]
with:
filename: tests/load/api_test.js
flags: --duration 5m --vus 100
env:
K6_CLOUD_TOKEN: ${{ secrets.K6_CLOUD_TOKEN }}
На CI запускаем облегчённый профиль (100 VU, 5 минут) — для базовой регрессии по производительности. Полный стресс-тест — по расписанию или перед релизом.
Что входит в работу?
Мы предоставляем полный пакет:
- Сценарии нагрузочного тестирования под ключ (k6/JMeter/Gatling)
- Отчёт с метриками и графиками (Grafana dashboard)
- Рекомендации по оптимизации узких мест
- Интеграция в ваш CI/CD (GitHub Actions, GitLab CI, Jenkins)
- Консультация команды backend-разработчиков по итогам
- Гарантия на корректность сценариев: бесплатная доработка, если бэкенд изменился
Как написать сценарий для k6: пошаговая инструкция
- Подготовить тестовые данные. Сформируйте CSV-файл с учётными записями пользователей (email, password) — минимум 100 записей.
- Создать сценарий. Импортируйте модули k6, определите опции (stages, thresholds) и основную функцию с авторизацией и типовыми запросами.
- Настроить окружение. Установите k6 локально или в Docker, подготовьте InfluxDB/Grafana для сбора метрик.
- Запустить прогон. Выполните команду
k6 run script.jsс нужными параметрами. - Проанализировать результаты. Изучите дашборды, найдите узкие места.
Опыт компании
Мы занимаемся нагрузочным тестированием 5+ лет. Выполнили более 50 проектов для fintech, e-commerce и social media приложений. Сертифицированные специалисты по k6 и JMeter гарантируют объективные результаты.
Сроки и стоимость
Ориентировочные сроки: 3–7 дней на написание сценариев, прогон и отчёт. Стоимость одного цикла тестирования начинается от 80 000 руб. и рассчитывается индивидуально после анализа вашей API-документации. Экономия на инфраструктуре после нашей оптимизации достигает 40%.
Свяжитесь с нами для консультации — мы бесплатно оценим ваш проект. Закажите нагрузочное тестирование, чтобы избежать даунтайма и потери пользователей.