Жүктеме және стресс-тестілеу
1) Терминдер мен мақсаттар
Load test - SLO-ға қарсы жұмыс диапазонында (target RPS/бәсекелестік) тексеру (мысалы, p95 <200 мс, error rate <0. 5%).
Stress test - шектен тыс шығу (CPU/БД/желінің қанығуына дейін/одан тыс), тозуды және қалпына келтіру механикасын бақылау.
Spike test - жүктеменің кенеттен жарылуы (минут ішінде N ×).
Soak/Endurance - ағып кетулерді, GC дрейфін, фрагменттеуді, кезектердің өсуін іздеу үшін ұзақ прогон (сағат/тәулік).
Capacity test - өткізу қабілеті платосын (saturation point) және қорларды есептеу.
Мақсаты: SLO растау, платоны бекіту, тар жерлерді түсіну, авто-масштабтау мен лимиттерді калибрлеу.
2) Трафик моделі: ашық vs жабық
Жабық модель (concurrency-driven): виртуалды пайдаланушылардың тіркелген саны (VUs), жауаптан кейін әрқайсысы think time жасайды.
Ашық модель (arrival-rate): жауаптарға қарамастан сұрау салулардың түсуінің белгіленген қарқындылығы (RPS).
Little’s Law: `L = λ W`
'L' - бір мезгілде қызмет көрсетілетін сұраулардың орташа саны,
'λ' - қарқындылық (RPS),
'W' - жауап берудің орташа уақыты.
Осыдан генератордың қажетті бәсекелестігін бағалау: 'concurrency ≈ target_RPS p95_latency'.
3) Өлшемдер: нені өлшейміз
SLI кідірістер: p50/p90/p95/p99 және p99. 9; «ыстық» және «суық» жолдар үшін жеке.
Қателер: '5xx', '4xx' (валид/валид емес), timeouts, aborted.
Өткізу қабілеті: тұрақты RPS, throughput ағындары/байт.
Ресурстар: CPU, RAM/heap, GC-үзілістер, дискілік IOPS/lat, желілік bandwidth, қосылыстар саны/FD.
Кезек және бэкпресер: тереңдігі, күту уақыты, shed/limited сұраулар саны.
Кэш тиімділігі: hit/miss, жылыту дауылдары.
ДБ/кэш/кезек: p95 сұраулар, блоктау, қайшылықтар, pool utilization.
4) Стендтер мен деректер
Конфигурациялық баламалылығы: бағдарламалық жасақтама нұсқалары, лимиттер (uLimit, conntrack), JVM/GC конфигурациясы, pool's.
Топология: LBs, CDN, WAF, TLS, сол желілік «хоптар».
Деректер: нақты бөлу (объектілердің өлшемдері, «ыстық «/» суық »кілттер, аймақтық).
Суық/жылы/ыстық старт: жеке аралықтар; міндетті түрде «суық» кэштерді тестілеу.
Өңді оқшаулау: релевантты емес джобтарды/крономаларды өшіру немесе олардың әсерін ескеру.
5) Сценарийлер (жүктеме профильдері)
1. Baseline: мақсатты RPS-ге дейін сатылы екпін, ұстап тұру 10-30 минут.
2. Ramp & Hold: мақсаттан жоғары X% -ға дейін бірқалыпты өсу, қалдықтарды ұстап тұру → талдау.
3. Spike: жедел × 2- × 1-5 минутқа 5 секіріс, содан кейін қайтару.
4. Stress to Failure: істен шыққанға дейінгі сатымен; SLO орындамаудың бірінші нүктесін және «сындыру» нүктесін тіркейміз.
5. Soak: трафиктің вариативтілігі 6-24 сағат (күн/түн), тұлғаларды/дрейфті қадағалаймыз.
6. Mixed: нақты таралуы бойынша эндпоинттердің қоспасы (Zipf/pareto), әртүрлі салмақтар.
6) Қадамдық процесс
SLO және мақсатты трафик профильдерін анықтау.
Жүктеме моделін таңдау (ашық/жабық), arrival-rate немесе VUs орнату.
Деректерді және «ыстық «/» суық »режимдерді дайындау.
Телеметрияны (трейс/метрика/логи), тест-жарақпен корелляцияны баптау.
Жылыту және айдау, артефактілерді жинау (CPU/heap, flame graphs, explain/slow-logs ДБ профильдері).
Тар жерлерді талдау, action items қалыптастыру.
Фикстерден кейін репрогон, базлайн және capacity playbook жаңартулары.
7) Тар жерлер және типтік фикстер
CPU-bound қызметі: профильдеу → ыстық функцияларды, аллокацияларды, тармақтарды жою; векторлау, кэш-friendly құрылымы.
Желі/TLS: keep-alive, HTTP/2/3, connection pooling, дұрыс таймауттар, сөйлесуді азайту.
БД: индекстер, батчингтер, дайындалған сұраулар, коннектілер пулы, R/W-бөлу, нәтижелерді кэштеу, сұрауларды дедупликациялау.
Кэштер: өлшемі, TTL, request coalescing, дауылдан қорғау, warming, аймақтық шарлар.
Кезектер/брокерлер: лимиттер/параллелизм, батч өлшемі, idempotent consumers, DLQ-төбелер.
Гарбатедж/үзіліс: тюнинг GC, буферлерді жалға алу, ақылға қонымды шекте object pooling.
I/O/диск: асинхронды енгізу/шығару, компрессия, ақылға қонымды деңгейдегі жауаптарды қысу.
8) Лимиттер және қорғау
Budget таймауттар: каскадтарды болдырмау үшін жоғарыдан төмен.
Rate limit/токен-бакеттер: «ұзақ өлімнің» орнына болжамды тозу.
Қанығу кезіндегі төмен басымдықты circuit breaker және шейдинг.
Backpressure: сигналдар және тізбектің ішкі параллелизмін шектеу.
Bulkheads: қауіпті эндпоинттерге пулдарды оқшаулау.
Idempotency: Ретра астында қауіпсіз қайталау кілті.
9) Құралдар және оларды қашан таңдау
k6 - қысқаша JS, arrival-rate, интеграция және бағандарды тамаша қолдау.
Gatling - Scala DSL, жоғары өнімді генератор.
JMeter - икемді, экожүйеге бай; протоколдарға/плагиндерге ыңғайлы.
Locust - Python сценарийлері, пайдаланушы флоуларының күрделі логикасы үшін қолайлы.
Vegeta/hey/wrk - HTTP-дегі микробенттер мен нүктелі итерулер.
tc/netem, toxiproxy - желілік тозуды инъекциялау.
Flamegraph/profiler - CPU/heap «ыстық орындарын» іздеу.
10) Мысалдар (эскиздер)
k6 (ашық модель, эндпоинттердің mix)
javascript import http from 'k6/http';
import { check, sleep } from 'k6';
export const options = {
scenarios: {
open_model: {
executor: 'constant-arrival-rate',
rate: 800, timeUnit: '1s', duration: '20m',
preAllocatedVUs: 500, maxVUs: 2000
}
},
thresholds: {
'http_req_duration{kind:hot}': ['p(95)<200'],
'http_req_failed': ['rate<0. 005']
}
};
export default function () {
const r = Math. random();
let res;
if (r < 0. 6) {
res = http. get('https://svc/api/hot', { tags: { kind: 'hot' }});
} else if (r < 0. 9) {
res = http. get('https://svc/api/warm', { tags: { kind: 'warm' }});
} else {
res = http. post('https://svc/api/heavy', JSON. stringify({ n: 1000 }), { headers: { 'Content-Type': 'application/json' }});
}
check(res, { 'status is 2xx': (r) => r. status >= 200 && r. status < 300 });
sleep(0. 2);
}Gatling (саты және дәнекер)
scala setUp(
scn. inject(
rampUsersPerSec(50) to 500 during (10 minutes),
constantUsersPerSec(500) during (20 minutes),
spikeUsers(2000). during(30. seconds)
)
). protocols(http. baseUrl("https://svc"))Жүктеме жоспары (YAML-скелет)
yaml profile: "mix-traffic"
targets:
- endpoint: GET /api/hot weight: 0. 6
- endpoint: GET /api/warm weight: 0. 3
- endpoint: POST /api/heavy weight: 0. 1 schedule:
- step: { rps: 300, hold: 10m }
- step: { rps: 600, hold: 10m }
- step: { rps: 900, hold: 10m }
guardrails:
slo:
p95_ms: 200 error_rate: 0. 5%
abort_if:
- metric: error_rate op: ">"
value: 2%
window: 2m11) Автоматтандыру және өмірлік цикл
Әрбір PR-да Perf-smoke (негізгі эндпоинттердің қысқа аралығы).
Есептері мен бейін артефактілері бар стейджердегі түнгі «capacity» прогондары.
CI/CD-дегі гейттер: регресс кезінде p95/p99> X базлайндағы немесе error rate өсуіндегі фэйл билд.
Базлайндарды нұсқалау және профильдерді/флеймграфтарды артефактілер ретінде сақтау.
Релеванттылық тегтері: қандай қызмет/эндпоинт жабылған, қандай трафик профилі пайдаланылған.
12) Қарсы үлгілер
Генератор және бір машинада тестілеу сервисі → бұрмаланған нәтижелер.
Тек жабық модель (VUs) үшін API-бекеттер → қалдықтарды төмендету және дұрыс емес бағалау.
Бос ДБ/кэш бойынша суықтай бастаусыз итеру.
Нақты бөлудің болмауы (барлық сұраулар бірдей).
Телеметрия жоқ (тек генератор жағынан RPS/latency).
Тұрақты базлайндарсыз және ортаны бақылаусыз салыстыру.
Себебін түзетудің орнына ұзартылған уақыт арқылы «оңтайландыру».
13) Сәулетшінің чек-парағы
1. SLO және үлгілік/ең жоғары жүктеме анықталған ба?
2. Дұрыс үлгі (open/closed) таңдалып, трафик профилі боялды ма?
3. Стенд конфигурациясы мен топологиясы бойынша баламалы, суық/ыстық режим бар ма?
4. Телеметрия мен профильдер қосылған, тест-жара белгілері қойылады ма?
5. Прогондар: baseline/ramp/spike/stress/soak - жабылған ба?
6. Қанығу нүктелері тіркеледі және қор жоспарланады (safety margin)?
7. Лимиттер, брейкерлер, бэкпресер, idempotency, шейдинг полистері реттелді ме?
8. p95/p99 регресіне CI-гейттер және error rate бар ма, базлайндар нұсқаланған ба?
9. Фикстен кейін - қуаты бойынша playbook-ты репрогондау және жаңарту?
10. Авто-масштабтау және апаттық режимдер жоспары құжатталды ма?
Қорытынды
Жүктеме және стресс-тестілеу - бұл бір реттік «жарыс» емес, үздіксіз инженерлік практика. Шынайы трафик моделі, дұрыс стендтер, телеметрия және CI/CD-дегі автоматтандыру өнімділікті «құпия сиқырдан» метрикалық басқарылатын қабілетке айналдырады: сіз төбеңіздің қайда екенін, қордың қаншалықты қауіпсіз екенін және қандай өзгерістер пайдаланушылардың тәжірибесін шынымен жақсартатынын білесіз.