Badanie obciążenia i naprężenie

Badanie obciążenia i naprężenie

1) Dlaczego go potrzebujesz

• Potwierdź pojemność (ile RPS/konkurencyjnych sesji system wytrzyma dane SLO).
• Znajdź wąskie gardła (CPU/IO/DB/networks/locks/pools).
• Ustaw budżety wydajności i bramy w CI/CD.
• Zmniejszenie ryzyka uwolnień (regresja p95/p99, wzrost błędów szczytowych).
• Przepustowość/koszt planu (skala i rezerwy).

2) Rodzaje badań perf

Ładunek: realistyczny ruch blisko szczytów; Walidacja SLO.
Stres: wzrost do/powyżej granicy → zachowanie degradacji, gdzie pęka.
Spike: szybki skok obciążenia → elastyczność/autoskale.
Moczenie/wytrzymałość: godziny/dzień → wycieki, rozdrobnienie, opóźnienie dryfu.
Pojemność/skalowalność: jak przepustowość/opóźnienie zmienia się wraz ze skalą; Prawo Amdal/Gustafson.
Dym perf: krótki „dym” bieg na każdym zwolnieniu (godność wykonania).

3) Modele generowania ruchu

Fixed VU/concurrency: 'N' użytkownicy, każde żądanie do → kolejka na klienta. Ryzyko ukrycia przeciążenia.
Szybkość przyjazdu: przepływ aplikacji o natężeniu (req/s), jak w rzeczywistym życiu. Bardziej poprawne dla publicznych API.

Prawo małego: 'L = α × W'.
W przypadku puli/usługi, minimalny równoległościomierz, na który składają się dodatki (20-50% zapasów).
W przypadku, gdy przepustowość jest równa przepustowości, „W” oznacza średni czas pracy.

4) Profile obciążenia i scenariusze

Mix podróży użytkownika: akcje skryptów (login, przeglądanie, depozyt, realizacja transakcji...).
Czas myślenia: pauzy użytkownika (dystrybucje: wykładnicze/lognormalne).
Profil danych: rozmiar odpowiedzi, ładunek użytkowy, zmienność parametrów.
Korelacja: kroki link (cookies/tokens/ID) jak w rzeczywistym przepływie.
Pamięć podręczna zimna/ciepła/gorąca: pojedyncze działa.
Czytaj vs Napisz: bilans odczytów/rekordów, idempotencja dla retras.
Multi-region: RTT, dystrybucja przez POP/ASN.

5) Środowisko badawcze

Izolacja: stojak jest blisko produktu w topologii/ustawieniach (ale nie „pokonać” produktu).
Dane: maskowanie PII, wolumeny, indeksy, jak w sprzedaży.
Generatory obciążenia: nie odpoczywać w stosunku do procesora/sieci; rozproszone biegacze, synchronizacja czasu.
Obserwowalność: mierniki/ścieżki/kłody, syntetyka na obwodzie, eksport profili procesora/hałdy.

6) Metryka i SLI

Przepustowość: RPS/Transakcje/sec

Opóźnienie: p50/p95/p99, TTFB, czas serwera vs sieci.
Błędy: udział błędów 5xx/4xx/domeny.
Nasycenie: CPU, load avg, GC, disk IOps/latency, network, pool wait.
Business SLI: ≤ 5s sukces depozytu, ≤ 2s potwierdzenie zamówienia.

Weź progi z SLO (na przykład, "99. 95% ≤ 300 ms"), wskaźnik spalania monitora podczas biegu.

7) Wykrywanie wąskich gardeł (technika)

1. Konsekwentnie rozgrzewaj system o 60-80% docelowego obciążenia.
2. Wzrost kroków (rampa) → ustalenie, gdzie p95/p99 i szybkość błędów rosną.

• kolejki w puli (DB/HTTP),
• wzrost WAIT/locks (DB),
• GC-pauzy/hałda,
• retransmitty sieciowe/utrata pakietów,
• brak opóźnienia dysku/pamięci podręcznej.
• 4. Lokalizacja: wyszukiwanie binarne ścieżką zapytania, profilerami (CPU/alloc/lock-profile).
• 5. Naprawić „butelkę” → dostrajanie → powtarzanie biegu.

8) Zachowanie w warunkach stresu

Wdzięczna degradacja: granice, wyłączniki, kolejki tylnego ciśnienia, akceptowane do przetwarzania.
Przekładki: maksymalnie 1, tylko idempotent; jitter; budżet przekaźnikowy ≤ 10% RPS.
Fail-open/Fail-closed: dla zależności innych niż krytyczne, zezwalaj na otwarcie awaryjne (cache/stubs).
Awaria kaskadowa: izolacja puli/kwot (grodzi), szybkie timeouts, „gładkie” wyłączanie funkcji (flagi funkcji).

9) Narzędzia (wybór zadania)

k6 (JavaScript, open/open-model, szybki, wygodny w CI).
JMeter (bogaty w ekosystem, GUI/CLI, wtyczki, ale cięższy).
Gatling (Scala DSL, wysoka wydajność).
Szarańcza (Python, elastyczność skryptowania).
Vegeta/hej/wrk (mikro-ławki i szybka kontrola).

Zasada: jedno „główne” narzędzie + lekkie CLI do wstrzykiwacza dymnego w PR.

10) Przykłady (snippets)

10. 1 k6 (model otwarty z szybkością przyjazdu)

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 (idea profilowa)

Grupa nici + Nić krocząca ила Gwint równoległy (otwarta).
Domyślne żądania HTTP, Menedżer plików cookie, Zestaw danych CSV.
Backend Listener → InfluxDB/Grafana; Twierdzenia według czasu/kodu.

10. 3 Szarańcza (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) Dane, korelacja, przygotowanie

Dane dotyczące nasion: katalogi, użytkownicy, salda, żetony - jak w sprzedaży.
Maskowanie/anonimizacja PII; generowanie syntetyki na szczycie rzeczywistych dystrybucji.
Korelacja: Wyodrębnić identyfikatory/żetony z odpowiedzi (RegExp/JSONPath) i użyć w kolejnych etapach.

12) Obserwowalność podczas biegów

Deski rozdzielcze RED (Wskaźnik, Błędy, Czas trwania) na trasach.
Przykłady - przejście od metryk do śladów (trace_id).
Dzienniki błędów: pobieranie próbek + agregacja, duplikaty/idempotencja.
System: CPU/GC/hałd, dyski/sieć, pool czekać.
DB: najlepsze zapytania, zamki, skany indeksowe, wzdęcia.

13) Automatyzacja i bramy wydajności

CI: krótkie runy w sprawie połączenia (np. k6 2-3 minuty) z progami.
Noc/tydzień: długi mocz/stres w oddzielnym nośniku; raportów i trendów.
Kanaryjskie wydania: analiza SLO (wskaźnik błędów, p95) jako „brama” promocji.
Regresje: stan podstawowy a budowa prądu; alert przy pogorszeniu> X%.

14) Planowanie przepustowości i koszty

Przepustowość krzywych → opóźnienie: zdefiniować punkt kolana - po p99 rośnie gwałtownie.
Skala-out: Efektywność skalowania (delta/delta węzła RPS).
Koszt: „RPS za $/godzinę”, rezerwa na wydarzenia szczytowe + rezerwa DR.

15) Anty-wzory

Wbić w prod bez kontroli lub testu w „pustym” środowisku, nie jak prod.
Zamknięty model ze stałymi sieciami VU ukrywającymi przeciążenie.
Brak czasu myślenia/danych → nierealistyczne trafienia w pamięci podręcznej, lub odwrotnie - burza do źródła.
Jeden skrypt „/ping „zamiast niestandardowego przepływu.
Brak obserwacji: „widzimy tylko RPS i średnie opóźnienie”.
Niekontrolowane przekładki → self-DDoS.
Mieszanie testu i optymalizacji bez ustalania hipotez/zmian.

16) Lista kontrolna (0-30 dni)

0-7 dni

Zdefiniuj SLI/SLO i docelowe profile ruchu (mix, think-time, data).
Wybierz narzędzie (k6/JMeter/szarańcza), podnieś deski rozdzielcze RED.
Przygotuj stoisko i dane nasion, wyłączyć ograniczenia/captchas osób trzecich.

8-20 dni

Scenariusze budowy: model otwarty (wskaźnik przyjazdu), pamięć podręczna zimna/ciepła/gorąca.
Uruchom obciążenie → stres → kolec; naprawić punkt kolana i wąskie gardła.
Wdrożenie bram wydajności w CI (micro-run).

21-30 dni

Test moczenia 4-24h: wycieki/dryfowanie GC, stabilizacja.
Ograniczenia dokumentów, plan przepustowości, ilustracje „RPS → p95/oshibki”.
Przygotuj książkę startową „jak zwiększyć ograniczenia/skalę” i „jak się rozkładać”.

17) Wskaźniki zapadalności

Istnieją realistyczne profile (mix, think-time, dane), które obejmują ≥ 80% ruchu.
Deski rozdzielcze RED + śledzenie są podłączone do wszystkich testów.
Bramki wydajność blokuje zwalnia podczas regeneracji p95/błędy.
Pojemność i punkt kolana są udokumentowane przez kluczowych usług.
Miesięczne biegi moczenia/stresu i sprawozdania z postępów.
Odporność na „skok” jest potwierdzona autoskalą i brakiem kaskady.

18) Wniosek

Badanie obciążenia to regularna praktyka inżynieryjna, a nie jednorazowy pomiar. "Modele rzeczywistych użytkowników (open-model), zmierzyć, co odzwierciedla doświadczenie klienta (SLI/SLO), zachować obserwowalność i bramy w CI/CD, przeprowadzić naprężenia/kolec/moczyć biegi i naprawić punkt kolana. Następnie zdarzenia szczytowe i czarne łabędzie zamieniają się w zarządzane scenariusze, a wydajność zmienia się w przewidywalny i wymierny parametr platformy.