Жүктемелік тестілеу және стресс-профильдер

Қысқаша түйіндеме

Жүктемелік тестілеу - бұл шынайы және экстремалды сценарийлермен өнімділік пен тұрақтылықты жүйелі тексеру. Табыстың негізі: дұрыс трафик моделі (open vs closed), бекітілген SLO, таза метрика (latency/throughput/қателер/қанығу), репрезентативті деректер, автоматтандыру және қайталану. Нәтиже - «RPS саны» емес, шешім: тар жерлер қайда, өнімділік қанша тұрады, істен шығу шегі қайда және оны қалай жылжыту керек.

SLO/SLI және мақсатты метриктер

SLO (мысал): p95 API ≤ 250 мс, p99 ≤ 600 мс; 0 ≤ қатесі. 3 %/30 күн.
SLI: latency (p50/p95/p99), throughput (RPS/CPS/QPS), saturation (CPU/heap/GC/FD/conn), ошибки (5xx, timeouts), очереди (depth/lag), DB (locks, slow queries), кэш (hit-ratio).
Қателер буджеттері және Saturation-триггерлер (мысалы, CPU> 75% немесе queue depth> X → деградация).

Тесттердің түрлері

1. Baseline/Benchmark - жалғыз сервис/эндпойнт, «мінсіз» шарттар.
2. Load - шынайы «жұмыс күні» + ramp-up/ramp-down.
3. Stress - жүктемені breakpoint деградациясы мен бекітілуіне дейін арттырамыз.
4. Spike - кенеттен секіру (секундына x2-x10).
5. Soak/Endurance - ұзақ уақыт жүру (8-72 сағат): жад кемуі, жасырындылық дрейфі.
6. Capacity - өнімділік қисығын құру және сыйымдылықты жоспарлау үшін сатылы жүктеме.
7. Degradation/Chaos-mix - жүктеме + ішінара істен шығулар (баяу ДБ, кэштің құлауы, «құлап қалған» аплинк).

Трафик үлгілері: Open vs Closed

Open model (интернет үшін шынайы): пайдаланушылар λ қарқындылығымен келеді (Poisson-ұқсас ағын). Егер жүйе тежесе, сұраулар «мұздатылмайды» емес, жинақталады.
Closed model: think-time бар виртуалды пайдаланушылардың (VU) тіркелген саны. Кідіріс өскен кезде RPS жасанды түрде құлдырайды - қорытындыларға абай болыңыз.
Ұсыным: Алдыңғы API үшін open model (k6 'arrival-rate'), ішкі синхронды сценарийлер үшін closed.

Жүктеме профильдері (үлгілер)

«Қалыпты күн»: базалық фон + күндізгі ауытқулар.
«Пик-ивент»: басталғанға дейін 10-30 минут (жылыту), басында өткір spike, плато, құйрық.
«Турнир/стрим»: баспалдақтар, аралықтарда қайталанған шыңдар.
«Инфрақұрылымның құлдырауы»: кэштің жартысы бос, бір аймақ ажыратылған, PSP жасырындылығын ұлғайту.
«Failover»: трафик 1-5 минут ішінде резервке ағады; авто-скейлді/HPA/Retry-дауылды тексереміз.

Деректер және қоршаған ортаны дайындау

Тестілік деректер: шынайы кардиналитет (провайдерлер, валюталар, елдер), «лас» өрістер, сұраныстарды бөлу (Pareto/Zipf).
Құпиялар/PII: анонимдеу; / PSP кілті - sandbox.
Қоршаған орта: бөлінген perf-стенд, интеграциядан оқшаулау (mock/stab), бекітілген нұсқалар.
Байқалуы: метрика (Prometheus), логи (Loki/ELK), трасса (OTel). Жауаптарда build-id белгілеңіз.

Ретрайлардың антиштормасы және

Ретраялар тек идемпотенттік операцияларға арналған; retry-budget (мысалы, трафиктің 10% ≤) қойыңыз.
Exponential backoff + jitter; «collapsing» бірдей GET.
Төлемдер үшін - идемпотенттік кілттер мен айқын мәртебелер.
thundering herd: кэш-локи, SWR, жергілікті семафорлардан қорғау.

Құралдар мен паттерндер

k6 (скрипттік, open-model, жақсы есептер), Locust (Python-сценарийлер), Gatling (Scala), JMeter (протоколдардың кең ауқымы).
Хаттамалар: HTTP/1. 1/2/3, gRPC, WebSocket, TCP/UDP; push серверін «GET ретінде» тестілемеңіз.
Трафикті генерациялау: генераторларды көлденең масштабтау, желілік тар жерді бақылау.
Профильді алу: pprof/async-profiler/ebpf жүктемемен, OTel трассасы.

k6 шағын мысалы (open-model + spike):

javascript import http from 'k6/http';
import {check, sleep} from 'k6';

export const options = {
scenarios: {
warmup: { executor: 'ramping-arrival-rate', startRate: 50, timeUnit: '1s',
preAllocatedVUs: 200, stages: [ { target: 200, duration: '5m' } ] },
spike: { executor: 'constant-arrival-rate', rate: 1200, timeUnit: '1s',
preAllocatedVUs: 2000, startTime: '6m', duration: '3m' }
},
thresholds: {
http_req_failed: ['rate<0. 3%'],
http_req_duration: ['p(95)<250', 'p(99)<600']
}
};

export default function () {
const res = http. get(`${__ENV. BASE_URL}/api/v1/catalog? c=${Math. floor(Math. random()1000)}`);
check(res, { 'status is 200': (r) => r. status === 200 });
sleep(Math. random()0. 9) ;//think time (for closed parts of the script)
}

Өткізу әдістемесі

1. Гипотеза → қандай тар жерлер болуы мүмкін (CPU, БД, кэш, желі, TLS, GC).
2. Профиль → сценарийлер/бағыттар, трафик үлестері, модельдер (open/closed), деректер.
3. Жылыту → кэш/коннектілер/TLS/интерпретаторлар.
4. Мақсатты қарқындылыққа дейін → сатының өсуі.
5. Плато → тұрақты метриктер мен трассаларды жинау.
6. Стресс/төмендеу → сынық нүктесін іздеу, авто-скейлді бақылау.
7. Талдау → метрикалық корреляция, flamegraph, есеп және өзгерістер жоспары.
8. Репруф → пайплайн CI (Regression Perf) арқылы қайталау.

Нәтижелерді талдау

«Жүктеме → кідіріс/қате» қисығы: тізені іздейміз (capacity).
Жасырындылық Breakdown: желі (DNS/TLS/connect), прокси, қосымша, БД, сыртқы қоңыраулар.
Сатурация: CPU> 75-85%, GC pause> p95, I/O күту, тапсырмалар кезегі.
Икемділік: автоскейл реакциясының уақыты (HPA/KEDA), «суық бастау», кэшті жылыту.
Құны: $/1000 RPS мақсатты SLO кезінде, шыңға бюджет болжамы.

Инженерлік практикалар

Тозу индикаторлары: «қалдықтар» p99, кезектердің өсуі, hit-ratio құлдырауы, ретрайлардың өсуі.
Файлдық дескрипторлардың, sysctl, conn-pool, 'reuseport', TLS-тізбектердің, OCSP шектерін алып тастаңыз.
БД: индекстер/жоспарлар/сұраулар кэші, қосылымдар пулы, батч-операциялар, продюсерлерге арналған backpressure.
Кэштер: өлшемі/eviction саясаты, ыстық кілттер, репликалар.
Желі/edge: HTTP/2/3, resumption ≥ 70%, Brotli, CDN кэш кілті, tiered-cache.

Жүктеме астындағы бақылау

Метриктер: жүйелік (CPU/mem/IO), runtime (GC/heap), желілік (RTT/loss/ECN), L7 (p95/99, 5xx/429), кезектер, БД/кэш кластерлері.
Трестер: «қалдықтарға» (tail-based) семплирлеуді, build-id/канарейка белгілерін қосу.
Логи: көлемді шектеумен қателерді біріктіру («үшінDOS» немесе «лог-пайплайн» болмауы үшін).
Эксперименттер: feature-flags және конфигалар есепте тіркелуі тиіс.

Автоматтандыру және CI/CD

Perf-jobs CI (smoke 3-5 мин, nightly 30-60 мин, weekly soak).
Рұқсат шектері: жасырындылық/қателер/ресурстар → регрессия кезінде «билд бұзамыз».
Артефакттар: графиктер, flamegraphs, профильдер, JSON-есептер (k6/jtl).
Деректер мен сценарийлерді нұсқалау, перф-сценарийлерді PR-тексеру.

iGaming/финтех ерекшелігі

Турнирлер/матчтар: spike + plateau; TLS/DNS/CDN жылыту, пулдардың жоғары лимиттері, боттар үшін «сұр» маршруттар.
Төлемдер/PSP: sandbox-лимиттер, теңсіздік, қатаң таймауттар; degrade-mode (анықтамалықтар кэші, кезек).
Джекпоттар/ивенттер: атомарлық және бірізділік, дубльдердің болмауы, RNG/көшбасшы борттарға жүктеме.
Антифрод/AML: ережелерге жүктеме/ML-скоринг, backpressure, оқиғаларды дедупликациялау.
Реттеуіш: шыңдар кезінде метриктер мен нұсқаларды логикалау, аудит үшін есептер.

Іске қосу парағы

SLO/SLI және «қызыл сызықтар» тіркелген (қате/жасырындылық/сатурация).
Жүктеме сценарийлері мен профильдері бекітілген (open/closed, spike/soak/stress).
Деректер шынайы, PII бүркемеленген, интеграция - sandbox/mock.
Бақылау дайын: метрика/трейс/логи, релиз тегтері.
Жүйе конфигтері (ulimit/sysctl/pools) құжатталған.
Авто-скейл/кэш жылыту жоспары және rollback критерийлері.
Командалардың шекті алерті және байланыс жоспары (on-call).
Есеп үлгісі (графиктер, қорытындылар, әрекеттер) дайындалды.

Типтік қателер

closed-model тесті «жасыл» нәтиже береді, ал өнімі түседі (open-модельді елемеуге болмайды).
Репрезентативті емес деректер (бір валюта/бір провайдер) → жалған қорытындылар.
Нөлдік дайындық: суық кэштер/TLS/коннектілер → басында жоғары латенттілік.
Шектеусіз ретрациялар → дауыл және каскадты құлау.
Барлық сервистер үшін бірдей профильдер → нақты «ыстық нүктелерді» өткізу.
Soak-прогондардың жоқтығы → есте сақтау және дрейф көрінбейді.
Айқын емес нәтижелер: трассалар/флеймграфтар жоқ → тар жерді оқшаулау мүмкін емес.

Шағын ойнатқыштар

Шекті өткізу қабілетін анықтау (breakpoint)

1. Әрбір 5-10 минут сайын жүктеменің 10-20% бойынша сатылар 2) p95 күрт өсетін және> SLO қателіктері болатын сәтті бекітеміз. 3) CPU/БД/кэш профильдерін аламыз. 4) Оңтайландыру жоспары және қайталау.

Ретрайлардың дауылдарын тежеу

1. retry-budget дегенді шектеу және backoff + jitter дегенді қосу. 2) request-collapsing/SWR енгізу. 3) «Деград-режимге» рұқсат ету (шектеулі функционалдық). 4) Ұқсастығын қайта тексеру.

Пик-ивент (турнир) - алдын ала жоспар

1. CDN/DNS/TLS/пулды жылыту. 2) HPA target ұлғайту, резерв дайындау. 3) Боттар үшін жеке rate-лимиттер. 4) «Пик-режим» дашбордтары, on-call байланыс көпірі.

Soak түні

1. 8-12 сағат тұрақты жүктеме. 2) heap/FD/conn/GC-pauses мониторингі. 3) Дельтаны p95 және hit-ratio салыстырып тексереміз. 4) Ағулар мен дрейфтерді тіркейміз.

Жиынтық

Жүктемелік тестілеу - бұл «RPS үшін жарыс» емес, инженерлік шешімдерді қабылдау процесі. Нақты профильдерді (әсіресе ашық модель) модельдеңіз, SLO-ны белгілеңіз, метриктер мен трассаларды алып тастаңыз, өнімділік тізгінін іздеңіз және өнімділік құнын есептеңіз. Прогондарды автоматтандырыңыз, ретраға қарсы дауылды ұстаңыз және ең жоғары оқиғаларды жоспарлаңыз - осылайша платформа ең шиеленісті сәттерде болжамды және тұрақты болады.