Жүк тестирлөө жана стресс

Жүк тестирлөө жана стресс

1) Эмне үчүн керек

• жөндөмдүүлүгүн ырастоо (канча RPS/атаандаш сессиялар берилген SLO менен система туруштук бере алат).
• Бөтөлкө оозун табуу (CPU/IO/DD/Networks/блоктор/пулдар).
• CI/CDдеги аткаруу бюджеттерин жана "гейттерди" орнотуу.
• релиздер коркунучун азайтуу (регрессия p95/p99, туу чокусунда каталардын өсүшү).
• Кубаттуулукту/наркты пландаштыруу (скейлинг жана резервдер).

2) сыноо түрлөрү

Load (иш жүгү): реалисттик трафик чокусуна жакын; SLO валидациясы.
Стресс (стресс): чегине чейин/жогору өсүшү → бузулган учурда жүрүм-туруму.
Spike (импульс): жүктүн тез секирүү → ийкемдүүлүк/автоскейл.
Soak/Endurance (узун): саат/күн → агып, үзүндү, latency drift.
Capacity/Scalability: throughput/latency scale-out кандай өзгөрөт; Амдал/Густафсон мыйзамы.
Smoke perf: ар бир бошотуу боюнча кыска "түтүн" чуркоо (аткаруу-санитардык).

3) трафик түзүү моделдери

Жабык модель (fixed VUs/concurrency): 'N' колдонуучулар, ар бир кардар → кезек суроо. Ашыкча жүктү жашыруу коркунучу.
Ачык модель (arrival rate): λ интенсивдүүлүгү менен арыздар агымы (req/s), реалдуу жашоодо сыяктуу. Коомдук API үчүн туура.

Литтл мыйзамы: 'L = λ × W'.
Бассейн/кызмат үчүн: минималдуу параллелизм ≈ 'λ × W' (запастын 20-50% кошуу).
Кайда 'λ' - throughput, 'W' - орточо тейлөө убактысы.

4) жүктөө Profiles жана жагдайлар

User journey mix: сценарийлердин үлүштөрү (login, browse, deposit, checkout...).
Think-Time: колдонуучунун тыныгуу (бөлүштүрүү: экспоненциалдык/логанормалдуу).
Data profile: жооптордун өлчөмү, payload, параметрлердин өзгөрмөлүүлүгү.
Корреляция: кадамдарды (кукилерди/токендерди/ID) чыныгы флоу катары байланыштырыңыз.
Суук/жылуу/ысык кэш: өзүнчө прогондор.
Reading vs Write: окуу/жазуу балансы, retrains үчүн ыктымалдуулук.
Көп аймак: RTT, POP/ASN бөлүштүрүү.

5) сыноо чөйрөсү

Изоляция: стенд топология/параметрлери боюнча прод жакын (бирок прод.
Маалыматтар: PII маскировкалоо, көлөмдөр, индекстер прод сыяктуу.
Жүктөө генераторлору: CPU/тармак таянган эмес; бөлүштүрүлгөн раннерлер, убакыт синхрондоштуруу.
Байкоо: метриктер/Trace/Logi, периметри боюнча синтетика, CPU/Heap профилдерин экспорттоо.

6) Метрика жана SLI

Throughput: секундасына RPS/бүтүмдөр.
Latency: p50/p95/p99, TTFB, server time vs network.
Errors: 5xx/4xx/домендик каталардын үлүшү.
Saturation: CPU, load avg, GC, диск IOps/жашыруун, network, pool wait.
Бизнес-SLI: 5s ≤ депозиттик ийгилиги, 2s ≤ тартиби ырастоо.

Босого маанилерин SLO (мисалы, "99. 95% ≤ 300 ms"), чуркоо учурунда бурн-rate мониторинг.

7) тар жерлерди издөө (ыкма)

1. Туруктуу 60-80% максаттуу жүктөө системасын жылытуу.
2. Кадамдарды көбөйтүү (рамп) → p95/p99 жана error-rate өсүп жаткан жерде чечүү.

• (DB/HTTP),
• WAIT/Locks (DD) өсүшү,
• GC-тыныгуу/heap,
• тармак retransmits/packet loss,
• дисктик латенттүүлүк/кэш каталар.
• 4. Локализациялоо: суроо жолу боюнча бинардык издөө, профилдер (CPU/alloc/lock-profile).
• 5. "Бөтөлкөнү" бекитүү → тюнинг → кайталоо.

8) Стресс астында жүрүм-турум

Graceful degradation: лимиттер, circuit-breakers, backpressure менен кезек, режими "кабыл алынган".
Retrais: максимум 1, гана idempotent; життер; бюджет RPS ≤ 10%.
Fail-open/Fail-closed: критикалык эмес көз карандылыктар үчүн fail-open жол (кэш/буктурма).
Cascading failure: пулду изоляциялоо/квота (bulkhead), тез таймауттар, функцияларды "жылмакай" өчүрүү (feature flags).

9) Куралдар (тапшырма үчүн тандоо)

k6 (JavaScript, ачык/ачык-модель, тез, CI ыңгайлуу).
JMeter (экосистемага бай, GUI/CLI, плагиндер, бирок оор).
Gatling (Scala DSL, жогорку аткаруу).
Locust (Python, скрипттердин ийкемдүүлүгү).
Vegeta/hey/wrk (микро-бенчилер жана тез текшерүү).

Эреже: бир "негизги" курал + PR-жылы smoke-аткаруу үчүн жеңил CLI.

10) Мисалдар (сниппеттер)

10. 1 k6 (arrival rate менен ачык модель)

js import http from 'k6/http';
import { sleep } from 'k6';

export const options = {
scenarios: {
open_model: {
executor: 'ramping-arrival-rate',
startRate: 200, timeUnit: '1s',
preAllocatedVUs: 200, maxVUs: 2000,
stages: [
{ target: 500, duration: '5m' },  // до 500 rps
{ target: 800, duration: '5m' },  // стресс
{ target: 0,  duration: '1m' }
]
}
},
thresholds: {
http_req_duration: ['p(95)<300', 'p(99)<800'],
http_req_failed: ['rate<0.005'],
},
};

export default function () {
const res = http.get(`${__ENV.BASE_URL}/api/catalog?limit=20`);
sleep(Math.random() 2); // think-time
}

10. 2 JMeter (кароо идеясы)

Thread Group + Stepping Thread или Concurrency Thread (open-like).
HTTP Request Defaults, Cookie Manager, CSV Data Set.
Backend Listener → InfluxDB/Grafana; Assertions убакыт/код боюнча.

10. 3 Locust (Python)

python from locust import HttpUser, task, between class WebUser(HttpUser):
wait_time = between(0.2, 2.0)
@task(5)
def browse(self): self.client.get("/api/catalog?limit=20")
@task(1)
def buy(self): self.client.post("/api/checkout", json={"sku":"A1","qty":1})

11) Маалыматтар, корреляция, даярдоо

Seed-маалыматтар: каталогдор, колдонуучулар, баланстар, токендер - прод сыяктуу.
PII жашыруу/анонимдештирүү; реалдуу бөлүштүрүү үстүнөн синтетика өндүрүү.
Корреляция: жооптордон ID/токендерди алып салыңыз (RegExp/JSONPath) жана кийинки кадамдарда колдонуңуз.

12) Прогондор учурунда байкоо

RED-дашборддор (Rate, Errors, Duration) каттамдар боюнча.
Exemplars: метрикадан трассаларга өтүү (trace_id).
ката Логи: sampling + агрегация, дубликат/боштук.
Системалык: CPU/GC/heap, дисктер/тармак, pool wait.
DD: Top-суроолор, блоктор, индекс-сканерлер, bloat.

13) Автоматташтыруу жана аткаруу оюндары

CI: merge боюнча кыска прогондор (мисалы, k6 2-3 мүнөт) босоголор менен.
Nightly/Weekly: өзүнчө чөйрөдө узун soak/стресс; отчеттор жана тенденциялар.
Канар релиздери: SLO анализи (error-rate, p95) "дарбазасы" промоушн катары.
Регрессия: baseline vs учурдагы билд; > X% начарлаганда алерталар.

14) кубаттуулугу жана наркы пландаштыруу

throughput → latency ийри сызыктары: knee point (тизе) аныктоо - андан кийин p99 кескин өсөт.
Skale чыгуу: масштабдоо натыйжалуулугун өлчөө (Delta RPS/Delta түйүндөрү).
Баасы: "$/саат үчүн RPS", жогорку окуялар үчүн камдык + DR-камдык.

15) Анти-үлгүлөрү

контролдоо же сыноо эмес, "бош" чөйрөдө прод уруп.
белгиленген VU менен жабык модель, ашыкча жашыруу.
think-time/берилиштердин жоктугу → реалдуу эмес кэш хиттери же тескерисинче - булакка бороон.
Бир скрипт "/ping "ордуна колдонуучу Flow.
байкоо жоктугу: "Биз RPS жана орточо кечигүү гана көрүп жатабыз".
өзүнөн-DDoS контролсуз Retra →.
Гипотезаларды/өзгөрүүлөрдү бекитпестен тестти жана оптималдаштырууну аралаштыруу.

16) Чек тизмеси (0-30 күн)

0-7 күн

SLI/SLO жана максаттуу трафик профилдерин (mix, think-time, маалыматтар) аныктаңыз.
Куралды тандоо (k6/JMeter/Locust), RED дашбордддорду көтөрүү.
стенд жана seed маалыматтарды даярдоо, үчүнчү тараптын чектөөлөрдү/каптчи өчүрүү.

8-20 күн

Сценарийлерди түзүңүз: open-model (arrival rate), муздак/жылуу/ысык кэш.
жүктөө → стресс → spike; knee point жана тар жерлерди бекитүү.
CI (микро-прогон) аткарууну киргизүү.

21-30 күн

Soak-Test 4-24 саат: агып/жылып GC, турукташтыруу.
Чектерди, кубаттуулук планын, "RPS → p95/каталар" иллюстрацияларын документтештирүү.
Runbook даярдоо "кантип чеги/Skale жогорулатуу үчүн" жана "деградация үчүн кантип".

17) Жетилүү метрикасы

трафиктин 80% ≥ камтыган реалдуу профилдер (mix, think-time, маалыматтар) бар.
RED-dashboard + Tracking бардык тесттер үчүн туташтырылган.
Аткаруу-гейтс p95/каталарды регрессиялоодо релиздерди бөгөттөйт.
Сыйымдуулугу жана knee пункту негизги кызматтар боюнча документтештирилген.
Айлык soak/стресс-прогондор жана динамикасы боюнча отчеттор.
"Spike" туруктуулугу autoscale жана cascade-fail жоктугу менен тастыкталган.

18) Корутунду

Жүк тестирлөө - бул бир жолку "өлчөө" эмес, үзгүлтүксүз инженердик практика. Чыныгы колдонуучуларды моделдөө (open-model), кардардын тажрыйбасын чагылдырган нерсени өлчөө (SLI/SLO), байкоо жүргүзүү жана CI/CDдеги "гейтс", стресс/spike/soak-прогондорду жүргүзүү жана knee point. Андан кийин эң жогорку окуялар жана "кара куулар" башкарылуучу сценарийлерге айланат, ал эми аткаруу сиздин платформаңыздын болжолдуу жана өлчөнүүчү параметрине айланат.