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

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

1) რატომ არის ეს აუცილებელი?

• დაადასტუროს შესაძლებლობები (რამდენი RPS/კონკურენტული სესია გაუძლებს სისტემას მოცემული SLO).
• იპოვნეთ ბოთლის კისრები (CPU/IO/BD/ქსელები/ბლოკირება/აუზები).
• CI/CD- ში სპექტაკლების ბიუჯეტებისა და „კარიბჭეების“ კონფიგურაცია.
• განთავისუფლების რისკის შემცირება (p95/p99 რეგრესია, შეცდომების ზრდა მწვერვალზე).
• დაგეგმეთ შესაძლებლობები/ღირებულება (სკაილი და რეზერვები).

2) პერფის ტესტების ტიპები

Load (სამუშაო დატვირთვა): რეალისტური ტრაფიკი მწვერვალებთან ახლოს; SLO ვალიდაცია.
სტრესი (სტრესი): ზრდა/ზემოთ - ქცევა დეგრადაციის დროს, სადაც ის იშლება.
Spike (იმპულსი): სწრაფი დატვირთვის ნახტომი, ელასტიურობა/ავტო სკეიტი.
Soak/Endurance (გრძელი): საათი/დღე - გაჟონვა, ფრაგმენტაცია, ლატენტობის დრიფტი.
Capacity/Scalability: როგორ იცვლება throughput/latency scale-out; ამდალის/გუსტაფსონის კანონი.
Smoke perf: მოკლე „კვამლის“ პროგონი თითოეულ გამოშვებაზე (სპექტაკლი-სანიტი).

3) ტრაფიკის გამომუშავების მოდელები

დახურული მოდელი (fixed VUs/concurrence): 'N' მომხმარებლები, თითოეული აკეთებს თხოვნებს რიგის კლიენტში. გადატვირთვის დამალვის რისკი.
ღია მოდელი (arrival rate): განაცხადების ნაკადი ინტენსივობით (req/s), როგორც რეალურ ცხოვრებაში. უფრო სწორია საზოგადოებრივი API- სთვის.

Little კანონი: 'L = -xW'.
აუზისთვის/მომსახურებისთვის: მინიმალური პარალელიზმი „“ × W „“ (დაამატეთ რეზერვის 20-50%).
სადაც 'with' არის throughput, 'W' არის საშუალო მომსახურების დრო.

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

User journey mix: სკრიპტების აქციები (login, browse, deposit, checkout...).
Think დრო: მომხმარებლის პაუზები (განაწილება: ექსპონენციალური/ლოგორმალური).
Data profile: პასუხების ზომა, payload, პარამეტრების ცვალებადობა.
კორელაცია: დააკავშირეთ ნაბიჯები (ქუქი/ნიშნები/ID), როგორც რეალურ ნაკადში.
ცივი/თბილი/ცხელი ქეში: ცალკეული საყრდენები.
Read vs Write: კითხვების/ჩანაწერების ბალანსი, რეპრესიების იდემპოტენტობა.
მულტფილმის რეგიონი: RTT, განაწილება POP/ASN- ზე.

5) ტესტირების გარემო

იზოლაცია: სტენდი ახლოს არის გაყიდვასთან ტოპოლოგიაში/პარამეტრებში (მაგრამ არა პროდ „ცემა“).
მონაცემები: PII შენიღბვა, მოცულობა, ინდექსები, როგორც გაყიდვაში.
დატვირთვის გენერატორები: ისინი არ ეყრდნობიან CPU/ქსელს; განაწილებული რანერები, დროის სინქრონიზაცია.
დაკვირვება: მეტრიკა/ტრეისი/ლოგები, პერიმეტრზე სინთეზური, CPU/heap პროფილების ექსპორტი.

6) მეტრიკა და SLI

Throughput: RPS/გარიგებები წამში.
Latency: p50/p95/p99, TTFB, server time vs network.
Errors: 5xx/4xx/დომენის შეცდომების წილი.
Saturation: CPU, load avg, GC, დისკი IOps/ლატენტობა, ქსელი, pool wait.
ბიზნეს SLI: ანაბრის წარმატება 5s, შეკვეთის დადასტურება 2s.

ბარიერი აიღეთ SLO- სგან (მაგალითად, "99. 95% - 300 მმ"), დააკვირდით ჭრილობის დროს.

7) ვიწრო ადგილების ძებნა (ტექნიკა)

1. სტაბილურად გაათბეთ სისტემა სამიზნე დატვირთვის 60-80% -ით.
2. გაზარდეთ ნაბიჯები (ramp) - დააფიქსირეთ სად იზრდება p95/p99 და error-rate.

• აუზების რიგები (DB/HTTP),
• WAIT/ლოკების ზრდა (BD),
• GC პაუზები/heap,
• ქსელის retransmits/packet loss,
• დისკის ლატენტობა/ქეში გამოტოვება.
• 4. ლოკალიზებული: ორობითი ძებნა მოთხოვნის გზაზე, პროფილაქტიკოსები (CPU/alloc/lock-profile).
• 5. დააფიქსირეთ „ბოთლი“ tuning - rogon განმეორება.

8) სტრესის ქვეშ მოქცევა

Graceful degradation: limites, circuit-breakers, ხაზები backpressure, რეჟიმი „დამუშავებულია“.
Retrai: მაქსიმუმ 1, მხოლოდ idempotent; ჯიტერი; ტირიფის ბიუჯეტი RPS- ის 10% -ს შეადგენს.
Fail Open/Fail-closed: დაუშვით fail Open (ქეში/დანამატები) არაკრიტიკული დამოკიდებულებებისთვის.
Cascading failure: ტყვიების/კვოტების იზოლაცია, სწრაფი ტაიმაუტები, ფუნქციების „გლუვი“ გამორთვა (feature flags).

9) ინსტრუმენტები (არჩევანი დავალებისთვის)

k6 (JavaScript, ღია/ღია მოდელი, სწრაფი, მოსახერხებელი CI).
JMeter (მდიდარი ეკოსისტემა, GUI/CLI, მოდულები, მაგრამ უფრო მძიმე).
Gatling (Scala DSL, მაღალი შესრულება).
Locust (პითონი, სკრიპტის მოქნილობა).
Vegeta/hey/wrk (მიკრო ბენჩი და სწრაფი შემოწმება).

წესი: ერთი „მთავარი“ ინსტრუმენტი + მსუბუქი CLI PR- ში სმოკის პერფისთვის.

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) მონაცემები, კორელაცია, მომზადება

თესვის მონაცემები: კატალოგები, მომხმარებლები, ნაშთები, ნიშნები - როგორც გაყიდვაში.
შენიღბვა/PII ანონიმიზაცია; სინთეზის წარმოქმნა რეალურ განაწილებებზე.
კორელაცია: ამოიღეთ ID/ნიშნები პასუხებიდან (RegExp/JSONPath) და გამოიყენეთ შემდგომი ნაბიჯები.

12) დაკვირვება

RED დაშბორდები (Rate, Errors, Duration) მარშრუტებზე.
Exemplars: გადასვლა მეტრიკიდან ტრასებზე (trace _ id).
შეცდომების ლოგიკა: სიმულაცია + აგრეგაცია, დუბლიკატები/იდემპოტენტობა.
სისტემური: CPU/GC/heap, დისკები/ქსელი, pool wait.
BD: საუკეთესო მოთხოვნები, ბლოკირება, ინდექსის სკანერები, bloat.

13) ავტომატიზაცია და შესრულება

CI: მოკლე რგოლები მერჯზე (მაგალითად, k6 2-3 წუთი) რეიდებით.
Nightly/Weekly: გრძელი soak/stress ცალკეულ გარემოში; მოხსენებები და ტენდენციები.
კანარის გამოშვებები: SLO ანალიზი (error-rate, p95), როგორც „კარიბჭე“.
რეგრესიები: მიმდინარე ბილეთი; ალერტები, როდესაც გაუარესდება> X%.

14) ტევადობის დაგეგმვა და ღირებულება

მრუდი throughput - latency: განსაზღვრეთ knee წერტილი (მუხლზე) - ამის შემდეგ p99 მკვეთრად იზრდება.
Skale-out: გაზომეთ მასშტაბის ეფექტურობა (RPS დელტა/კვანძების დელტა).
ღირებულება: „RPS $/საათში“, სარეზერვო პიკის მოვლენებისთვის + DR რეზერვი.

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

ცემა პროდუქტებში კონტროლის გარეშე ან ტესტირება „ცარიელ“ გარემოში, რომელიც არ ჰგავს პროდუქტს.
დახურული მოდელი ფიქსირებული VU- ით, რომელიც მალავს გადატვირთვას.
think time/მონაცემების არარსებობა არის ქეშის არარეალური ჰიტები ან პირიქით, ქარიშხალი წყაროებისთვის.
ერთი სცენარი „/პინგი “მომხმარებლის ნაკადის ნაცვლად.
დაკვირვების ნაკლებობა: „ჩვენ ვხედავთ მხოლოდ RPS და საშუალო შეფერხებას“.
უკონტროლო ჭრილობები - თვით-DDoS.
ტესტისა და ოპტიმიზაციის შერევა ჰიპოთეზების/ცვლილებების დაფიქსირების გარეშე.

16) ჩეკის სია (0-30 დღე)

0-7 დღე

განსაზღვრეთ SLI/SLO და მიზნობრივი ტრაფიკის პროფილები (mix, think-time, მონაცემები).
შეარჩიეთ ინსტრუმენტი (k6/JMeter/Locust), ასწიეთ RED dashbords.
მოამზადეთ სტენდი და თესლის მონაცემები, გამორთეთ მესამე მხარის ლიმიტები/კაპტჩი.

8-20 დღე

ააშენეთ სკრიპტები: ღია მოდელი, ცივი/თბილი/ცხელი ქეში.
Spike - stress spike; დააფიქსირეთ რაუნდი და ვიწრო ადგილები.
გააცნობიერეთ სპექტაკლის კარიბჭეები CI (მიკრო-რგოლი).

21-30 დღე

Soak ტესტი 4-24 საათი: გაჟონვა/GC დრიფტი, სტაბილიზაცია.
აღწერეთ საზღვრები, ტევადობის გეგმა, ილუსტრაციები „RPS-p95/შეცდომები“.
მოამზადეთ runbook „როგორ გავზარდოთ limites/skale“ და „როგორ გავაფართოვოთ“.

17) სიმწიფის მეტრიკა

არსებობს რეალისტური პროფილები (mix, think დრო, მონაცემები), რომლებიც მოიცავს ტრაფიკის 80% -ს.
RED დაშბორდები + კვალი უკავშირდება ყველა ტესტს.
სპექტაკლის კარიბჭეები ბლოკავს გამოშვებებს p95/შეცდომების რეგრესიით.
შესაძლებლობები და რაუნდი დოკუმენტირებულია საკვანძო სერვისებზე.
ყოველთვიური soak/stress progons და მოხსენებები დინამიკის შესახებ.
Spike- ის წინააღმდეგობა დადასტურებულია სკალით და cascade fail- ის არარსებობით.

18) დასკვნა

დატვირთული ტესტირება რეგულარული საინჟინრო პრაქტიკაა და არა ერთჯერადი „გაზომვა“. მოდელირება მოახდინეთ რეალურ მომხმარებლებზე (ღია მოდელი), გაზომეთ ის, რაც ასახავს კლიენტის გამოცდილებას (SLI/SLO), შეინარჩუნეთ დაკვირვება და „კარიბჭეები“ CI/CD- ში, ჩაატარეთ stress/spike/soak-progons და დააფიქსირეთ knee წერტილი. შემდეგ პიკის მოვლენები და „შავი გედები“ გადაიქცევა კონტროლირებად სცენარებად, ხოლო პროდუქტიულობა გადაიქცევა თქვენი პლატფორმის პროგნოზირებად და გაზომილ პარამეტრად.