Стрес-тестування: пошук breaking point та меж навантаження

Стрес-тестування: пошук breaking point та меж навантаження

Ваш сайт витримує пікове навантаження? Ми допомагаємо знайти точку відмови (breaking point) до того, як це зроблять ваші користувачі. Стрес-тестування — це навантажувальний тест, який навмисно перевищує нормальні пікові значення. Наприклад, для інтернет-магазину перед розпродажем ми імітуємо до 10 000 віртуальних користувачів, щоб побачити, при якому RPS починаються помилки.

Стрес-тест виявляє вузькі місця: БД, CPU, пам'ять, мережу. Результат — конкретні цифри: p95 latency, error rate, максимальний RPS. Це дозволяє запобігти простоям і заощадити до 40% бюджету на інфраструктуру. За даними нашої практики (100+ проєктів), клієнти скорочують витрати на сервери на 30-50% після оптимізації за результатами стрес-тесту. Наприклад, один клієнт заощадив $2000 на місяць після оптимізації за нашими рекомендаціями.

Як визначити точку відмови (breaking point)?

Ми використовуємо ступінчастий профіль навантаження за допомогою k6 — інструмента, який споживає в 5 разів менше ресурсів, ніж Apache JMeter, і перевершує його за продуктивністю в 5 разів. k6 написаний на Go і підтримує скрипти на JavaScript, що робить його ідеальним для CI/CD. Процес включає чотири етапи:

1. Визначення baseline. Запускаємо нормальне навантаження (50–70% від очікуваного піку) і фіксуємо p95 latency, error rate, CPU/memory.
2. Ступінчасте збільшення. Підвищуємо навантаження кроками по 10–20% кожні 2–5 хвилин до появи помилок або критичної затримки.
3. Пошук breaking point. Продовжуємо до деградації (error rate > 5% або latency > 5× baseline).
4. Відновлення. Знімаємо навантаження і вимірюємо час повернення системи до норми.

// tests/stress/breaking-point.js
import http from 'k6/http'
import { check, sleep } from 'k6'
import { Rate, Trend, Counter } from 'k6/metrics'

const errorRate = new Rate('errors')
const requestsPerSecond = new Counter('requests_per_second')

export const options = {
  stages: [
    { duration: '2m',  target: 50 },
    { duration: '3m',  target: 50 },
    { duration: '2m',  target: 100 },
    { duration: '3m',  target: 100 },
    { duration: '2m',  target: 200 },
    { duration: '3m',  target: 200 },
    { duration: '2m',  target: 400 },
    { duration: '3m',  target: 400 },
    { duration: '2m',  target: 800 },
    { duration: '3m',  target: 800 },
    { duration: '2m',  target: 1600 },
    { duration: '3m',  target: 1600 },
    { duration: '5m',  target: 50 },
    { duration: '3m',  target: 0 },
  ],
  thresholds: {
    http_req_duration: [
      { threshold: 'p(95)<2000', abortOnFail: false },
    ],
    errors: [
      { threshold: 'rate<0.1', abortOnFail: false }
    ]
  }
}

const BASE_URL = __ENV.BASE_URL || 'http://localhost:3000'

export default function() {
  const responses = http.batch([
    ['GET', `${BASE_URL}/api/products?limit=20`],
    ['GET', `${BASE_URL}/api/categories`],
  ])

  responses.forEach(r => {
    check(r, { 'status 2xx': (r) => r.status >= 200 && r.status < 300 })
    errorRate.add(r.status >= 400)
  })

  requestsPerSecond.add(2)
  sleep(0.1)
}

export function handleSummary(data) {
  const stages = analyzeStages(data)
  return {
    'stress-results.json': JSON.stringify(data, null, 2),
    stdout: generateReport(stages)
  }
}

function generateReport(stages) {
  return `
=== STRESS TEST REPORT ===
Breaking Point Analysis:
${stages.map(s => `  VUs: ${s.vus} | p95: ${s.p95}ms | Errors: ${(s.errorRate*100).toFixed(1)}%`).join('\n')}
`
}

Чому важливо фіксувати відновлення?

Надійність системи визначається не тільки тим, як вона тримає навантаження, але і як швидко повертається в норму після його зняття. Повільне відновлення (більше 2 хвилин) — ознака проблем з пулом з'єднань, витоком пам'яті або неправильною конфігурацією кешів. Ми обов'язково тестуємо цей сценарій, щоб гарантувати стабільність навіть після аварійного піку.

Кейс з практики: нещодавно ми провели стрес-тест для маркетплейсу. При навантаженні 500 RPS все було стабільно, але після зняття навантаження система відновлювалася 4 хвилини. Діагностика показала невірні налаштування пулу підключень до PostgreSQL. Після оптимізації час відновлення скоротився до 30 секунд, а пропускна здатність зросла до 1500 RPS.

Моніторинг під час тесту

Паралельно зі стрес-тестом ми запускаємо збір системних метрик на цільових серверах. Приклад скрипту моніторингу CPU, пам'яті, завантаження та стану PostgreSQL:

#!/bin/bash
# scripts/monitor-stress-test.sh

TARGET_HOST="app-server-ip"
INTERVAL=10

while true; do
  TIMESTAMP=$(date -u +%Y-%m-%dT%H:%M:%SZ)

  ssh $TARGET_HOST "
    echo -n '$TIMESTAMP '
    echo -n 'cpu:'; top -bn1 | grep 'Cpu(s)' | awk '{print \$2}'; echo -n ' '
    echo -n 'mem:'; free | grep Mem | awk '{print \$3/\$2 * 100}'; echo -n ' '
    echo -n 'load:'; cat /proc/loadavg | awk '{print \$1}'
    echo -n 'conns:'; ss -s | grep -o 'estab [0-9]*' | awk '{print \$2}'
  "

  ssh $TARGET_HOST "
    PGPASSWORD=pass psql -U app -d appdb -t -c \"
      SELECT 'active_queries:', count(*) FROM pg_stat_activity
        WHERE state = 'active' AND query NOT LIKE '%pg_stat%';
      SELECT 'long_queries:', count(*) FROM pg_stat_activity
        WHERE state = 'active' AND query_start < NOW() - interval '5 seconds';
      SELECT 'locks:', count(*) FROM pg_locks WHERE NOT granted;
    \"
  "

  sleep $INTERVAL
done | tee stress-monitor.log

Як аналізувати результати з Prometheus та Grafana?

Ми відправляємо метрики k6 в Prometheus через Remote Write і будуємо дашборди в Grafana. Приклад PromQL для візуалізації:

# RPS в реальному часі
rate(k6_http_reqs_total[30s])

# Error rate за часом (знайти момент деградації)
rate(k6_http_req_failed_total[30s]) / rate(k6_http_reqs_total[30s])

# p95 latency в реальному часі
histogram_quantile(0.95, rate(k6_http_req_duration_seconds_bucket[30s]))

Скрипт Python для автоматичного пошуку breaking point:

# analyze_stress_results.py
import json
import pandas as pd

def analyze_breaking_point(results_file):
    with open(results_file) as f:
        data = json.load(f)

    metrics = data['metrics']

    analysis = {
        'max_rps_before_errors': find_max_sustainable_rps(metrics),
        'error_threshold_rps': find_error_threshold(metrics),
        'latency_degradation_point': find_latency_degradation(metrics),
        'recovery_time_seconds': find_recovery_time(metrics),
    }

    print("=== Breaking Point Analysis ===")
    print(f"Max sustainable RPS (< 1% errors): {analysis['max_rps_before_errors']}")
    print(f"Error threshold RPS: {analysis['error_threshold_rps']}")
    print(f"p95 > 1s at RPS: {analysis['latency_degradation_point']}")
    print(f"Recovery time after load removal: {analysis['recovery_time_seconds']}s")

    if analysis['max_rps_before_errors'] < 100:
        print("\n[!] LOW capacity. Consider: DB connection pooling, caching, horizontal scaling")
    elif analysis['recovery_time_seconds'] > 120:
        print("\n[!] SLOW recovery. Consider: circuit breakers, graceful degradation")

    return analysis

Коли слід проводити стрес-тестування?

Рекомендуємо проводити стрес-тести після кожного значущого релізу, при зміні архітектури (наприклад, міграція на новий хостинг або додавання кешування), а також планово раз на квартал для моніторингу деградації продуктивності. Це допоможе своєчасно виявити проблеми з продуктивністю та уникнути простоїв.

Типові вузькі місця та діагностика

Порівняння інструментів для стрес-тестування

k6 в 5 разів ефективніший за JMeter, що підтверджено бенчмарками (Grafana k6 documentation). Ми використовуємо його у всіх проєктах. Понад 10 років досвіду в навантажувальному тестуванні дозволяють нам швидко виявляти вузькі місця та давати точні рекомендації.

Що входить в роботу під ключ

• Документація по виявленому breaking point (RPS, latency, error rate)
• Дашборди Grafana з історією тестів та кореляцією метрик
• Рекомендації з оптимізації з пріоритетами (критичні / бажані)
• Повторне тестування після внесення змін
• Звіт про відновлення системи після навантаження

Строки та вартість

Стандартний стрес-тест з описаним сценарієм займає 2–3 робочих дні. Вартість розраховується індивідуально залежно від складності архітектури та кількості цільових ендпоінтів — орієнтовно від 500 євро. Зв'яжіться з нами для точної оцінки вашого проєкту — ми підберемо профіль навантаження та узгодимо метрики.

Отримавши результати, ви зможете впевнено масштабувати сайт, уникаючи простоїв у пікові моменти. Наш досвід — 100+ успішних стрес-тестів для проєктів різного масштабу — гарантує об'єктивність та прикладну користь. Замовте стрес-тест під ключ і отримайте детальний звіт з рекомендаціями. Або пишіть нам, щоб обговорити ваш проєкт — оцінимо проект безкоштовно.

Чому юніт-тести важливі, але не панацея?

Баг, знайдений юніт-тестом, коштує хвилини виправлення. Той самий баг у продакшені — години інциденту, компенсації та втрата довіри. На проекті інтернет-магазину помилка в розрахунку знижки пройшла ручне тестування, потрапила в прод і за 4 години обробила 37 замовлень за нульовою ціною. Автотест на граничні випадки розрахунку зловив би її при першому ж push. Оцініть свій проект — ми проведемо аудит поточного покриття і дамо рекомендації.

Jest — стандарт для JavaScript/TypeScript, але юніт-тести виправдані тільки там, де є ізольована логіка: функції трансформації, валідатори, бізнес-правила, утиліти. Тестувати React-компоненти через Jest + Testing Library правильно для поведінкових тестів: «кнопка з'являється після завантаження», «форма показує помилку при порожньому email». Снепшот-тести (toMatchSnapshot) — пастка: вони ламаються при будь-якій зміні верстки і стають шумом, який розробники оновлюють не дивлячись. Покриття коду (code coverage) — погана метрика якості: 80% coverage можна отримати тестами, які нічого не перевіряють. Coverage показує, що код виконався, а не те, що він працює правильно.

Vitest як альтернатива Jest для Vite-проектів: в 10–20 разів швидше завдяки нативним ES modules без трансформації через Babel. Для монорепозиторіїв з тисячами тестів різниця у швидкості відчутна. Детальніше про юніт-тестування.

Як налаштувати E2E тести, які не будуть flaky?

Playwright обійшов Cypress за ключовими параметрами: нативна підтримка multi-tab, multi-origin, iframe; паралельне виконання на рівні тестів; WebKit, Firefox, Chromium з коробки; немає iframe для додатку — тести працюють в реальному браузері.

Playwright codegen записує дії та генерує тест — хороша точка старту, але згенерований код потрібно рефакторити. Локатори за text content крихкі: getByRole('button', { name: 'Оформить заказ' }) — стійкіше, ніж locator('.btn-primary').

Page Object Model — стандарт організації E2E тестів. Кожна сторінка — окремий клас з методами замість прямих локаторів. Коли кнопка переїхала з хедера в сайдбар — міняємо в одному місці, не шукаємо по всіх тестах.

// Погано
await page.click('#submit');
await page.waitForTimeout(2000);
await expect(page.locator('.success')).toBeVisible();

// Добре
await page.click('#submit');
await page.waitForResponse(resp =>
  resp.url().includes('/api/orders') && resp.status() === 201
);
await expect(page.getByRole('alert', { name: /заказ создан/i })).toBeVisible();

Наші інженери гарантують стабільність тестів у CI. Документація Playwright — основний інструмент на проектах з мільйонами користувачів.

Навантажувальне тестування з k6

k6 — інструмент для навантажувального тестування з JavaScript API. Сценарії пишуться як код, версіонуються в git, запускаються в CI. Три основних сценарії:

• Spike test — різке зростання навантаження: 0 → 1000 користувачів за 30 секунд. Імітує запуск рекламної кампанії. Показує здатність системи реагувати на піки.
• Soak test — стабільне навантаження на 2–4 години. Виявляє memory leaks, connection pool exhaustion, деградацію продуктивності.
• Stress test — навантаження вище розрахункової (150–200% від очікуваного піку). Показує точку відмови та graceful degradation.

Порогові значення:

thresholds: {
  http_req_duration: ['p95<500', 'p99<1000'],
  http_req_failed: ['rate<0.01'],
}

p95 < 500ms означає: 95% запитів відповідають швидше півсекунди. Якщо поріг не виконується — k6 завершується з кодом помилки, CI-пайплайн падає.

На одному проекті інтернет-магазину ми виявили деградацію API на 4-й годині тесту: p95 зріс з 200ms до 2s через витік з'єднань. Після оптимізації клієнт заощадив значну суму на інцидентах та зайвих ресурсах. Отримайте аналогічний аудит вашого проекту — замовте навантажувальне тестування.

Як Core Web Vitals впливають на ранжування?

Google використовує Core Web Vitals у ранжуванні. Lighthouse CLI в CI-пайплайні: при кожному деплої перевіряємо, що LCP < 2.5s, CLS < 0.1, INP < 200ms. Детальніше про веб-продуктивність. Реальні проблеми, які Lighthouse знаходить:

• Hero image без атрибутів width/height: CLS 0.35 при завантаженні.
• JavaScript-бандл 2.1MB синхронно блокує парсинг: INP 450ms.
• Шрифти без font-display: swap: невидимий текст до завантаження шрифту (FOIT).
• Неоптимізований hero image 4MB: LCP 8.2s.

Lighthouse CI (lhci) зберігає історію метрик і надсилає коментар до PR з деградацією. За даними Google, 53% користувачів залишають сайт при завантаженні довше 3 секунд — наші тести запобігають таким втратам.

Піраміда тестування в проекті

Що входить в роботу?

• Аудит поточного покриття та визначення критичних user flows.
• Написання unit-тестів для ключової бізнес-логіки, інтеграційних тестів для API, E2E для сценаріїв користувача.
• Налаштування паралельного виконання в CI (sharded workers для Playwright).
• Навантажувальне тестування зі звітом та рекомендаціями.
• Документація за тест-кейсами, навчання вашої команди роботі з тестами.
• Гарантійна підтримка 1 місяць після впровадження.

Процес роботи

1. Аналітика — аудит поточного тестування, виявлення слабких місць, визначення пріоритетів.
2. Проектування — вибір інструментів, написання тест-плану, узгодження.
3. Реалізація — написання тестів, інтеграція в CI.
4. Тестування — прогін всіх рівнів, аналіз результатів, виправлення помилок.
5. Деплой — запуск в прод, моніторинг метрик, навчання команди.

Терміни

Налаштування повного тест-пайплайна (Jest + Playwright + k6 + Lighthouse CI) з нуля: 2–4 тижні. Покриття E2E-тестами існуючого проекту (20–30 сценаріїв): 3–6 тижнів. Навантажувальне тестування зі звітом та рекомендаціями: 1–2 тижні. Вартість розраховується індивідуально після аудиту.

Готові обговорити ваш проект? Залиште заявку — ми проведемо аудит поточного тестування безкоштовно і запропонуємо план з економією до 60% часу на інциденти. Отримайте консультацію з тестування веб-додатків — напишіть нам.