Стрес-тестування: пошук 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+ успішних стрес-тестів для проєктів різного масштабу — гарантує об'єктивність та прикладну користь. Замовте стрес-тест під ключ і отримайте детальний звіт з рекомендаціями. Або пишіть нам, щоб обговорити ваш проєкт — оцінимо проект безкоштовно.