Навантажувальне тестування 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 }}