Yük testi və stress

1) Niyə lazımdır

Məqsədlər:

Tutumu təsdiq edin (sistem müəyyən edilmiş SLO-da neçə RPS/rəqabət sessiyasına tab gətirə bilər).
Butulka boynunu (CPU/IO/DB/şəbəkə/kilid/hovuzlar) tapın.
CI/CD-də performans-büdcələri və «geytləri» konfiqurasiya edin.
Buraxılış riskini azaltın (regressiya p95/p99, zirvədə artan səhvlər).
Tutum/dəyəri planlaşdırın (Skale-out və ehtiyatlar).

2) Perf test növləri

Yük (iş yükü): pik yaxın real trafik; SLO validasiya.
Stress (stress): həddindən artıq böyümək → pozulduğu yerdəki pozulma davranışları.
Spike (impuls): yükün sürətli sıçrayışı → elastiklik/avtoskeyl.
Soak/Endurance (davamlı): saat/gün → sızma, parçalanma, sürüklənmə latency.
Capacity/Scalability: scale-out zamanı throughput/latency necə dəyişir; Amdal/Gustafson qanunu.
Smoke perf: hər buraxılışda qısa «tüstü» qaçışı (performans-sanitari).

3) Trafik istehsal modelləri

Qapalı model (fixed VUs/concurrency): 'N' istifadəçilər, hər kəs müştəri → növbə sorğu edir. Həddindən artıq yükü gizlətmək riski.
Açıq model (arrival rate): real həyatda olduğu kimi λ intensivliyi (req/s) ilə müraciət axını. İctimai API üçün daha düzgün.

Little Law: 'L = λ × W'.
Hovuz/xidmət üçün: minimum paralellik ≈ 'λ × W' (20-50% ehtiyat əlavə edin).
Harada 'λ' - throughput, 'W' - orta xidmət vaxtıdır.

4) Yükləmə profilləri və ssenariləri

User journey mix: ssenarilərin payları (login, browse, deposit, checkout...).
Think-time: istifadəçi fasilələri (paylama: eksponensial/lognormal).
Data profile: cavabların ölçüsü, payload, parametrlərin dəyişkənliyi.
Korrelyasiya: real flow kimi addımları (cookies/token/ID) bağlayın.
Soyuq/isti/isti keşlər: ayrı-ayrı keçidlər.
Read vs Write: oxu/qeydlərin balansı, retrajlar üçün idempotentlik.
Multi-region: RTT, POP/ASN paylanması.

5) Test mühiti

İzolyasiya: Stand topologiya/parametrlərə görə məhsula yaxındır (lakin məhsulu «döymək» deyil).
Məlumatlar: PII maskalanması, həcmləri, indeksləri prodda olduğu kimi.
Yük generatorları: CPU/şəbəkədə dayanmır; paylanmış rannerlər, vaxt sinxronizasiyası.
Müşahidə: metriklər/treys/loi, perimetrdə sintetika, CPU/heap profillərinin ixracı.

6) Metrika və SLI

Throughput: RPS/saniyədə əməliyyatlar.
Latency: p50/p95/p99, TTFB, server time vs network.
Errors: 5xx/4xx/domen səhvlərinin payı.
Saturation: CPU, yük avg, GC, disk IOps/gecikmə, network, pool wait.
Biznes SLI: 5s ≤ depozit müvəffəqiyyəti, 2s ≤ sifariş təsdiqi.

Eşik qiymətlərini SLO-dan götürün (məsələn, "99. 95% ≤ 300 ms"), qaçış zamanı burn-rate izləyin.

7) Dar yerlərin axtarışı (metodika)

1. Hədəf yükün 60-80% -i üçün sistemi sabit şəkildə qızdırın.
2. (Ramp) → p95/p99 və error-rate böyüdüyü yerləri düzəldin.

3. p99 sıçrayışlarını aşağıdakılarla müqayisə edin:

hovuzlarda növbələr (DB/HTTP),
WAIT/lock (DB) böyüməsi,
GC-fasilələr/heap,
şəbəkə retransmits/packet loss,
disk gizlilik/cache səhvlər.
4. Lokallaşdırın: sorğu yolu ilə ikili axtarış, profilləşdiricilər (CPU/alloc/lock-profile).
5. «Şüşəni» düzəldin → sazlama → qaçışın təkrarı.

8) Stress altında davranış

Graceful degradation: limitlər, circuit-breakers, backpressure ilə növbələr, rejimi «emal qəbul».
Retrajlar: maksimum 1, yalnız idempotent; Jitter; retraj büdcəsi ≤ 10% RPS.
Fail-open/Fail-closed: qeyri-kritik asılılıqlar üçün fail-open (önbellək/qapaq) icazə.
Cascading failure: hovuzların/kvotaların izolyasiyası (bulkhead), sürətli vaxtlar, funksiyaların «hamar» dayandırılması (feature flags).

9) Alətlər (tapşırıq üçün seçim)

k6 (JavaScript, açıq/açıq-model, sürətli, CI-də rahatdır).
JMeter (ekosistem zəngin, GUI/CLI, plugins, lakin daha ağır).
Gatling (Scala DSL, yüksək performans).
Locust (Python, ssenarilərin çevikliyi).
Vegeta/hey/wrk (mikro-benci və sürətli yoxlama).

Qayda: bir «əsas» alət + PR-də smoke-perf üçün yüngül CLI.

10) Nümunələr (snippetlər)

10. 1 k6 (arrival rate ilə açıq model)

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'} ,//stress
{ 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 (profil ideyası)

Thread Group + Stepping Thread или Concurrency Thread (open-like).
HTTP Request Defaults, Cookie Manager, CSV Data Set.
Backend Listener → InfluxDB/Grafana; Assertions vaxt/kod.

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) Məlumatlar, korrelyasiya, hazırlıq

Seed-data: kataloqlar, istifadəçilər, balanslar, tokenlər - prodda olduğu kimi.
PII maskalanması/anonimləşdirilməsi; real paylama üzərində sintetik istehsal.
Korrelyasiya: Cavablardan ID/tokenləri çıxarın (RegExp/JSONPath) və sonrakı addımlarda istifadə edin.

12) Qaçış zamanı müşahidə

RED-daşbordları (Rate, Errors, Duration) marşrutlar üzrə.
Exemplars: metriklərdən marşrutlara keçid (trace_id).
Səhv qeydləri: sampling + aqreqasiya, dublikatlar/idempotentlik.
Sistem: CPU/GC/heap, disklər/şəbəkə, pool wait.
BD: Top sorğular, kilidləmə, indeks skanerləri, bloat.

13) Avtomatlaşdırma və performans geytaları

CI: Qısamüddətli merge (məsələn, k6 2-3 dəqiqə).
Nightly/Weekly: ayrı bir mühitdə uzun soak/stress; hesabatlar və trendlər.
Kanarya relizləri: SLO analizi (error-rate, p95) promosyonun «qapısı» kimi.
Reqressiya: baseline vs cari bild; pisləşmə zamanı alertlər> X%.

14) Tutum və dəyəri planlaşdırılması

throughput → latency əyriləri: knee point (diz) - ondan sonra p99 kəskin böyüyür.
Skale-out: Ölçmə effektivliyini ölçün (delta RPS/delta düyünləri).
Qiymət: «$/saat üçün RPS», pik hadisələr üçün ehtiyat + DR-ehtiyat.

15) Anti-nümunələr

Prod-a nəzarət etmədən vurun və ya prod-a bənzəməyən «boş» mühitdə test edin.
Sabit VU ilə qapalı model, həddindən artıq yüklənməni gizlədir.
Think-time/data → qeyri-real cash hitləri və ya əksinə - mənbələrə fırtına.
Xüsusi flow əvəzinə bir «/ping »ssenarisi.
Müşahidə edilməməsi: «Biz yalnız RPS və orta gecikmə görürük».
Nəzarətsiz retralar → öz-DDoS.
Hipotezlər/dəyişikliklər qeyd etmədən test və optimallaşdırma qarışdırın.

16) Çek siyahısı (0-30 gün)

0-7 gün

SLI/SLO və hədəf trafik profillərini (mix, think-time, məlumatlar) müəyyən edin.
Alət seçin (k6/JMeter/Locust), RED dashboard qaldırın.
Stand və seed məlumatlarını hazırlayın, üçüncü tərəf limitlərini/kaptçalarını söndürün.

8-20 gün

Ssenarilər qurun: open-model (arrival rate), soyuq/isti/isti cache.
load → stress → spike başlayın; knee point və dar yerləri düzəltmək.
Performans geytalarını CI-yə (mikro-qaçış) daxil edin.

21-30 gün

Soak testi 4-24 saat: sızma/drift GC, stabilizasiya.
Limitləri, tutum planını, «RPS → p95/səhvlər» illüstrasiyalarını sənədləşdirin.
Runbook «limitləri artırmaq üçün necə/skale» və «deqradasiya necə» hazırlayın.

17) Yetkinlik metrikası

Trafikin 80% -ni əhatə edən real profillər (mix, think-time, data) ≥.
RED-dashboard + tracking bütün testlər üçün bağlıdır.
Performans geytləri p95/səhv reqressiyasında buraxılışları bloklayır.
Tutum və knee point əsas xidmətlər ilə sənədləşdirilmişdir.
Aylıq soak/stress qaçışları və dinamika hesabatları.
«Spike» -ə qarşı müqavimət avtoskeyl və cascade-fail olmaması ilə təsdiqlənir.

18) Nəticə

Yük testi bir dəfəlik «ölçmə» deyil, müntəzəm mühəndislik təcrübəsidir. Real istifadəçiləri modelləşdirin (open-model), müştərinin təcrübəsini əks etdirən şeyləri ölçün (SLI/SLO), müşahidə və «geytaları» CI/CD-də saxlayın, stress/spike/soak-qaçışları həyata keçirin və knee point-i düzəldin. Sonra pik hadisələr və «qara qu quşu» idarə olunan ssenarilərə, performans isə platformanızın proqnozlaşdırıla bilən və ölçülə bilən parametrinə çevrilir.

Yük testi və stress