Нагрузочное тестирование API мобильного приложения: k6, JMeter, Gatling

Представьте: ваше мобильное приложение выходит в топ App Store, за ночь приходит 50 000 новых пользователей. Утром вы видите даунтайм бэкенда — ошибки 504 на всех экранах. Без нагрузочного тестирования бэкенд не выдержит пиковых всплесков от push-уведомлений или рекламной кампании. Мы проводим полный цикл тестирования: пишем сценарии на k6, JMeter или Gatling, настраиваем профили нагрузки, анализируем узкие места и даём рекомендации по оптимизации. k6 в 3 раза быстрее запускает сценарии по сравнению с JMeter на больших объёмах, а его сценарии компактны и легко читаются. Ниже разберём процесс на примере типичного мобильного API.

Почему нагрузочное тестирование API критично для мобильного приложения?

Мобильный трафик отличается от веба: устройства отправляют множество одновременных запросов, работают в фоновом режиме, используют непредсказуемые сетевые условия. Без профилирования нагрузки бэкенд может не выдержать пиковых нагрузок. Типичная проблема — бэкенд рассчитан на среднюю нагрузку, а не на пиковые всплески от push-уведомлений или рекламной кампании.

Как мы выбираем инструмент?

Три основных инструмента, каждый под свою задачу:

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

Какие профили нагрузки нужны?

Мобильный трафик неравномерен. Мы определяем четыре типичных профиля:

k6 run --out influxdb=http://localhost:8086/k6 scenario.js 

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