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