დატვირთვა და სტრესის ტესტირება

1) ტერმინები და მიზნები

Load test - ტესტირება სამუშაო დიაპაზონში (target RPS/კონკურენტუნარიანობა) SLO- ს წინააღმდეგ (მაგალითად, p95 <200 ms, error rate <0). 5%).
Stress test - გასასვლელი გარეთ (CPU/BD/ქსელის გაჯერებამდე), აღდგენის დეგრადაციისა და მექანიკის დაკვირვება.
Spike test - მკვეთრი დატვირთვა (× N წუთში).
Soak/Endurance - გრძელი პროგონი (საათი/დღე) გაჟონვის, GC დრიფტის, ფრაგმენტაციის, რიგის ზრდის მოსაძებნად.
Capacity test - გამტარუნარიანობის პლატოსა და რეზერვების გაანგარიშება.

მიზნები: დაადასტუროთ SLO, დააფიქსიროთ პლატო, გაიგოთ ვიწრო ადგილები, დააგემოვნოთ მანქანები და შეზღუდვები.

2) ტრაფიკის მოდელი: ღია დახურული

დახურული მოდელი (Concurrence-driven): ვირტუალური მომხმარებლების ფიქსირებული რაოდენობა (VUs), თითოეული პასუხის შემდეგ ხდება think დრო.
ღია მოდელი: მოთხოვნის მიღების ფიქსირებული ინტენსივობა (RPS), მიუხედავად პასუხებისა.

Little’s Law: `L = λ W`

'L' - ერთდროულად მომსახურებული მოთხოვნების საშუალო რაოდენობა,

'- ინტენსივობა (RPS),

'W' არის საშუალო პასუხი.
აქედან გამომდინარე, გენერატორის სწორი კონკურენტუნარიანობის შეფასება: „კონკურენცია - target _ RPS p95 _ ლატენტობა“.

3) მეტრიკა: რას ვზომავთ

SLI შეფერხებები: p50/p90/p95/p99 და კუდი p99. 9; ცალკეული ცხელი და ცივი ბილიკებისთვის.
შეცდომები: '5xx', '4xx' (მოქმედი/არასტაბილური), timeouts, aborted.
გამტარუნარიანობა: სტაბილური RPS, throughput ნაკადები/ბაიტი.
რესურსები: CPU, RAM/heap, GC პაუზები, დისკი IOPS/lat, ქსელის ბანდიტი, კავშირების რაოდენობა/FD.
ხაზები და ზურგჩანთები: სიღრმე, ლოდინის დრო, შეფუთული/შეზღუდული მოთხოვნების რაოდენობა.
ქეშის ეფექტურობა: hit/miss, გათბობის ქარიშხალი.
BD/ქეში/რიგები: p95 მოთხოვნა, დაბლოკვა, კონფლიქტები, აუზი utilization.

4) სტენდი და მონაცემები

კონფიგურაციის ეკვივალენტი: პროგრამული უზრუნველყოფის ვერსიები, ლიმიტები (uLimit, conntrack), JVM/GC კონფიგურაცია, pool 'y.
ტოპოლოგია: LBs, CDN, WAF, TLS, იგივე ქსელის „ჰოპები“.
მონაცემები: რეალისტური განაწილება (ობიექტების ზომები, „ცხელი „/“ ცივი “გასაღებები, რეგიონულობა).
ცივი/თბილი/ცხელი დასაწყისი: ცალკეული საყრდენები; დარწმუნდით, რომ შეამოწმეთ „ცივი“ ქეში.
ფონის იზოლაცია: არარელევანტური ჯობების/კრონომების გამორთვა ან მათი ეფექტის გათვალისწინება.

5) სკრიპტები (დატვირთვის პროფილები)

1. Baseline: საფეხურის აჩქარება სამიზნე RPS- მდე, გამართვა 10-30 წთ

2. Ramp & Hold: გლუვი ზრდა X% -მდე აღემატება მიზანს, კუდის შენარჩუნება და ანალიზი.
3. Spike: მყისიერი × 2- × 5 სიჩქარე 1-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 BD).
ვიწრო ადგილების ანალიზი, მოქმედების items- ის შექმნა.
რეპროგონი ფიქსაციის შემდეგ, ბაზლაინის განახლება და კაპიტალის თამაში.

7) ვიწრო ადგილები და ტიპიური ფიქსაცია

CPU-bound სერვისი: პროფილირება, ცხელი ფუნქციების აღმოფხვრა, ალოკაცია, ფილიალები; ვექტორიზაცია, ქეში-მეგობრული სტრუქტურა.
ქსელი/TLS: keep-alive, HTTP/2/3, შეკრება, სწორი ტაიმაუტები, მატყლის შემცირება.
BD: ინდექსები, პეპლები, მომზადებული თხოვნები, კონექტორების აუზები, R/W განცალკევება, შედეგების ქეშირება, მოთხოვნის დედაპლაცია.
ქეში: ზომა, TTL, request coalescing, დაცვა ქარიშხლებისგან, warming, რეგიონალური ბურთები.
რიგები/ბროკერები: შერჩევის/პარალელიზმის ლიმიტები, ბრძოლების ზომა, იდუმალი საკონსულტაციო, DLQ ჭერი.
გარბაგება/პაუზები: GC tuning, ბუფერების დაქირავება, გონივრული დიაპაზონი.
I/O/დისკი: ასინქრონული შეყვანა/გამომავალი, კომპრესია, პასუხების შეკუმშვა გონივრული დონით.

8) ლიმიტები და დაცვა

Budget Taimauts: ზემოდან ქვემოდან, რათა თავიდან აიცილოთ კასკადები.
Rate limit/tocken backets: პროგნოზირებადი დეგრადაცია „გრძელი სიკვდილის“ ნაცვლად.
Circuit breaker და დაბალი პრიორიტეტული shading გაჯერებით.
Backpressure: სიგნალები და პარალელიზმის შეზღუდვა ჯაჭვში.
Bulkheads: ტყვიების იზოლაცია კრიტიკული ენდოინტებისთვის.
Idempotence: გასაღებები უსაფრთხო გამეორებისთვის.

9) ინსტრუმენტები და როდის უნდა აირჩიონ ისინი

k6 - laconic JS, შესანიშნავი მხარდაჭერა arrival-rate, ინტეგრაცია და გრაფიკები.
Gatling - Scala DSL, მაღალი ხარისხის გენერატორი.
JMeter - მოქნილი, მდიდარი ეკოსისტემა; მოსახერხებელი ოქმებისთვის/დანამატებისთვის.
Locust - Python სცენარები მოსახერხებელია მომხმარებლის ნაკადების რთული ლოგიკისთვის.
Vegeta/hey/wrk - მიკრობები და წერტილოვანი ღიობები HTTP.
tc/netem, toxiproxy - ქსელის დეგრადაციის ინექცია.
Flamegraph/profiler - „ცხელი ადგილების“ ძებნა CPU/heap.

10) მაგალითები (ესკიზები)

k6 (ღია მოდელი, mix endpoints)

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: 2m

11) ავტომატიზაცია და სასიცოცხლო ციკლი

Perf-smoke თითოეულ PR- ში (ძირითადი ენდოინების მოკლე პროგონი).
ღამის „კაპიტალი“ გაფუჭებულია სტეჯზე, მოხსენებებით და პროფილის არტეფაქტებით.
კარიბჭეები CI/CD- ში: ბილეთის დაფა p95/p99> ბაზლაინის X% ან error rate- ის ზრდა.
ბაზლაინების ვერსია და პროფილების/ფლეიმგრაფების, როგორც არტეფაქტების შენახვა.
შესაბამისობის ჭდეები: რომელი სერვისი/ენდოინტი დაფარულია, რომელი ტრაფიკის პროფილი გამოიყენება.

12) ანტი შაბლონები

გენერატორი და ტესტირების სერვისი ერთ მანქანაში არის დამახინჯებული შედეგები.
API ბეკებისთვის მხოლოდ დახურული მოდელი (VUs) არის კუდის დაქვეითება და არასწორი შეფასება.
ცარიელი BD/ქეში გადახურვა ცივი დაწყების გარეშე.
რეალისტური განაწილების არარსებობა (ყველა მოთხოვნა იგივეა).
არ არსებობს ტელემეტრია (მხოლოდ RPS/latence გენერატორის მხრიდან).
შედარება სტაბილური ბაზილიკების და გარემოს კონტროლის გარეშე.
„ოპტიმიზაცია“ გაზრდილი ტაიმუტის საშუალებით, მიზეზის გამოსწორების ნაცვლად.

13) არქიტექტორის ჩეკის სია

1. განსაზღვრულია SLO და ტიპიური/მწვერვალი დატვირთვა?
2. შეირჩა სწორი მოდელი (Open/closed) და მოხატული ტრაფიკის პროფილი?
3. სტენდი ექვემდებარება კონფიგურაციას და ტოპოლოგიას, არის ცივი/ცხელი რეჟიმი?
4. ჩართულია ტელემეტრია და პროფილები, იქმნება ტესტის ჭრილობის ეტიკეტები?
5. Progons: baseline/ramp/spike/stress/soak - დაფარული?
6. ფიქსირდება გაჯერების წერტილები და დაგეგმილია რეზერვი?
7. შედგენილია ლიმიტები, ბრეიკერები, ზურგჩანთები, იდემპოტენციები, შეიდინგის პოლიტიკა?
8. არსებობს CI კარიბჭეები p95/p99 რეგრესისთვის და error rate- ისთვის, ვერსირებულია ბაზლაინები?
9. Fixis- ის შემდეგ - playbook- ის აღდგენა და ენერგიის განახლება?
10. დოკუმენტირებულია მანქანის მასშტაბისა და გადაუდებელი რეჟიმების გეგმა?

დასკვნა

დატვირთვა და სტრესის ტესტირება არ არის ერთჯერადი „რბოლა“, არამედ უწყვეტი საინჟინრო პრაქტიკა. ტრეფიკის რეალისტური მოდელი, სწორი სტენდები, ტელემეტრია და ავტომატიზაცია CI/CD- ში „საიდუმლო მაგიიდან“ პროდუქტიულობას მეტრიკებით კონტროლირებად შესაძლებლობად აქცევს: თქვენ იცით, სად არის თქვენი ჭერი, რამდენად უსაფრთხოა რეზერვი და რა ცვლილებები ნამდვილად აუმჯობესებს მომხმარებლის გამოცდილებას.