Badanie obciążeń i naprężeń
1) Warunki i cele
Test obciążenia - test w zakresie roboczym (docelowy RPS/konkurencja) przeciwko SLO (na przykład p95 <200 ms, wskaźnik błędu <0. 5%).
Test naprężeniowy - wykraczający poza (przed/ponad nasycenie sieci procesora/DB/), obserwując mechanikę degradacji i odzysku.
Badanie kolca - ostre wybuchy obciążenia (× N przez minuty).
Mocz/wytrzymałość - długi okres (godziny/dzień), aby znaleźć przecieki, dryf GC, fragmentacja, wzrost kolejki.
Test pojemności - obliczenie płaskowyżu przepustowości (punkt nasycenia) i rezerw.
Cele: potwierdzić SLO, naprawić płaskowyż, zrozumieć wąskie gardła, kalibrować automatyczne skalowanie i ograniczenia.
2) Model ruchu: otwarty vs zamknięty
Model zamknięty (napędzany jednocześnie): stała liczba użytkowników wirtualnych (VU), każdy po odpowiedzi sprawia, że czas myślenia.
Model otwarty (wskaźnik przyjazdu): stała stawka żądań (RPS), niezależnie od odpowiedzi.
Prawo małego: 'L = W'
"L' to średnia liczba równocześnie obsługiwanych wniosków,
„na” - natężenie (RPS),
'W' to średni czas reakcji.
Stąd też ocena niezbędnej konkurencyjności wytwórcy: „współistnienie” target_RPS p95_latency'.
3) Metryka: co mierzymy
Opóźnienie SLI: p50/p90/p95/p99 i ogon p99. 9; oddzielne dla ścieżek „gorących” i „zimnych”.
Błędy: '5xx', '4xx' (poprawne/nieprawidłowe), timeouts, aborted.
Przepustowość: trwały RPS, strumienie przepustowości/bajty.
Zasoby: procesor, pamięć RAM/hałas, pauzy GC, IOPS dysku/lat, przepustowość sieci, liczba połączeń/FD.
Kolejki i Backprescher: głębokość, czas oczekiwania, liczba rekwizycji/ograniczone żądania.
Wydajność pamięci podręcznej: hit/miss, burze rozgrzewające.
DB/caches/kolejki: zapytania p95, zamki, konflikty, wykorzystanie puli.
4) Stoiska i dane
Równoważność konfiguracji: wersje oprogramowania, limity (uLimit, conntrack), JVM/GC config, puli.
Topologia: LB, CDN, WAF, TLS, ta sama sieć "chmiel'.
Dane: realistyczne dystrybucje (rozmiary obiektów, „gorące „/” zimne „klucze, regionalność).
Zimny/ciepły/gorący start: pojedyncze biegi; Pamiętaj, aby przetestować „zimne” bufory.
Izolacja tła: Wyłączyć nieistotne miejsca pracy/kronomie lub rozliczyć ich wpływ.
5) Scenariusze (profile obciążenia)
1. Wartość wyjściowa: przyspieszenie etapu do docelowego RPS, trzymać 10-30 min.
2. Ramp & Hold: gładki wzrost do X% powyżej celu, retencja → analiza ogona.
3. Spike: natychmiastowy × 2- × 5 splash przez 1-5 minut, a następnie powrót.
4. Stres do niepowodzenia: kroki do niepowodzeń; naprawić pierwszy punkt awarii SLO i punkt „break”.
5. Mocz: 6-24 godziny z zmiennością ruchu (dzień/noc), zegarek na twarze/dryf.
6. Mieszane: mieszanina punktów końcowych według rzeczywistej dystrybucji (Zipf/pareto), różne masy.
6) Proces krok po kroku
Zdefiniuj SLO i docelowe profile ruchu.
Wybierz model obciążenia (otwarte/zamknięte), ustawić szybkość przyjazdu lub VU.
Przygotuj dane i tryby „gorące „/” zimne „.
Ustawić telemetrię (trasy/mierniki/kłody), korelację z przebiegiem badania.
Nagrzewanie i uruchamianie, zbieranie artefaktów (profile CPU/hałasu, wykresy płomienia, wyjaśnienie/powolne dzienniki DB).
Analiza wąskich gardeł, tworzenie elementów działania.
Reprogon po poprawkach, aktualizacji początkowej i odtwarzania pojemności.
7) Wąskie gardła i typowe poprawki
Usługa związana procesorem: profilowanie → eliminacja gorących funkcji, przydziałów, oddziałów; wektoryzacja, struktura przyjazna pamięci podręcznej.
Sieć/TLS: utrzymać się przy życiu, HTTP/2/3, łączenie połączeń, poprawne timeouts, zmniejszone rozmowy.
DB: indeksy, zestawianie, przygotowywane zapytania, pula połączeń, separacja R/W, buforowanie wyników, deduplikacja zapytań.
Bufety: rozmiar, TTL, koalescencja, ochrona przed burzą, ocieplenie, regionalne kulki.
Kolejki/maklerzy: limity akceptacji/paralelizm, wielkość partii, konsumenci idempotent, sufity DLQ.
Śmieci/pauzy: dostrajanie GC, wynajem buforów, łączenie obiektów w rozsądnych granicach.
I/O/dysk: asynchroniczny I/O, kompresja, kompresja odpowiedzi o rozsądnym poziomie.
8) Granice i ochrona
Harmonogramy budżetowe: od góry do dołu, aby uniknąć kaskad.
Limit stawki/wiadra tokenowe: przewidywalna degradacja zamiast „długiej śmierci”.
Wyłącznik i niski priorytet zacienienia nasycenia.
Ciśnienie wsteczne: sygnały i ograniczające współistnienie w głębi łańcucha.
Grodzie: baseny izolacyjne dla krytycznych punktów końcowych.
Idempotencja: klucze do bezpiecznych powtórzeń w ramach retras.
9) Narzędzia i kiedy je wybrać
k6 - lakoniczny JS, doskonałe wsparcie dla szybkości przyjazdu, integracji i wykresów.
Gatling - Scala DSL, wysokowydajny generator.
JMeter - elastyczny, bogaty ekosystem; wygodne dla protokołów/wtyczek.
Szarańcza - skrypty Pythona, wygodne dla złożonej logiki przepływu użytkownika.
Vegeta/hej/wrk - mikrobenchies i punkt działa na HTTP.
tc/netem, toksyproksy - wtrysk degradacji sieci.
Flamegraph/profiler - wyszukiwanie ciepłych punktów procesora/hałasu.
10) Przykłady (szkice)
k6 (model otwarty, punkty końcowe mieszane)
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);
}Zbieranie (kroki i kolce)
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"))Plan obciążenia (szkielet 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: 2m11) Automatyzacja i cykl życia
Dym perfowy w każdym PR (krótka długość kluczowych punktów końcowych).
Nocne „pojemność” działa na scenie z raportów i artefaktów profilowych.
Bramki w CI/CD: zbudować plik przy regresji p95/p99> X% wzrostu wartości wyjściowej lub wskaźnika błędu.
Wersioning linii podstawowych i przechowywanie profili/flamegrafów jako artefaktów.
Znaczniki istotności: które usługi/punkt końcowy są objęte, który profil ruchu jest używany.
12) Anty-wzory
Generator i usługa testowa na tej samej maszynie → zniekształcone wyniki.
Tylko zamknięty model (VU) dla APIbacks → niedostrzelanie i błędne ocenianie.
Działa na pustej bazie danych/pamięci podręcznej bez zimnego startu.
Brak realistycznych dystrybucji (wszystkie zapytania są takie same).
Brak telemetrii (RPS/latency tylko po stronie generatora).
Porównanie bez stabilnych linii podstawowych i kontroli środowiska.
„Optymalizacja” poprzez zwiększony czas zamiast korygować przyczynę.
13) Lista kontrolna architekta
1. SLO i typowe/szczyt obciążenia zdefiniowane?
2. Czy wybrano odpowiedni model (otwarty/zamknięty) i profil ruchu?
3. Stoisko jest równoważne w konfiguracji i topologii, czy istnieje tryb zimny/gorący?
4. Telemetria i profile włączone, rany testowe oznaczone?
5. Biegi: wyjściowa/rampa/skok/stres/moczenie - pokryte?
6. Czy punkty nasycenia są stałe i planowany margines bezpieczeństwa?
7. Skonfigurowane limity, wyłączniki, backprescher, idempotencja, zasady zacieniania?
8. Czy są bramki CI do regresji p95/p99 i szybkości błędów, czy linie podstawowe są wersjonowane?
9. Po naprawach - reprogon i odtwarzanie aktualizacji mocy?
10. Auto zoom i plan awaryjny udokumentowane?
Wniosek
Testy obciążenia i naprężeń to nie jednorazowe „wyścigi”, ale ciągła praktyka inżynieryjna. Realistyczny model ruchu, prawidłowe stoiska, telemetria i automatyka w CI/CD zmieniają wydajność z „tajnej magii” w zdolność napędzaną metryką: wiesz, gdzie jest twój sufit, jak bezpieczny jest magazyn i jakie zmiany naprawdę poprawiają doświadczenie użytkownika.