Usługi / Testy obciążeniowe
WydajnośćWiemy, gdzie system pęka, zanim zrobi to produkcja
k6 odtwarza ruch. Grafana pokazuje p95, błędy i saturację. Kubernetes mówi, czy limit i autoscaling trzymają. ntopng widać, gdy wąskie gardło jest w sieci, nie w aplikacji. Wynik to decyzja o architekturze, nie sam wykres.
Jak to składa się w całość
Obciążenie, obserwacja, pojemność, sieć
Sam generator bez dashboardu nie mówi, co skalować. Składamy k6, Grafanę, klaster i widok sieci w jeden wniosek dla architektury.
- Pierwszy test wydajności i ćwiczenie failover to dwa osobne terminy.
- Software house może dostać ten sam harness na kolejnym kliencie, ze zmianą modelu ruchu.
Scenariusz z analityki, nie z losowej liczby RPS
k6 (i JMeter tam, gdzie już jest) dostaje model: logowanie, checkout, webhook, raport nocny. Spike, soak i stress są osobnymi sesjami. Harness zostaje w repo, da się odpalić przed pikem.
Model
Udział ścieżek z produkcji. Think time, cache, warmup. Bez tego test kłamie.
Rodzaje
Load, spike, soak, stress. Soak łapie wyciek po godzinach, nie po dwóch minutach.
Bramka
SLO w teście: p95, błąd, saturacja. Fail pipeline, gdy budżet pęka.
Powtórka
Ten sam skrypt na stagingu klienta software house i przed kampanią.
Wykres związany z aplikacją, bazą i kolejką
k6 bez observacji to RPS w próżni. Patrzymy na p95 API, locki bazy, CPU, GC, długość kolejki. Decyzja: indeks, cache, więcej poda, inny limit, nie „dołóż instancji w ciemno”.
Korelacja
VU, latencja, błąd i saturacja na jednej osi czasu.
Warstwy
App, baza, cache, kolejka, storage. Wąskie gardło ma nazwę.
Porównanie
Przed zmianą i po. Ten sam scenariusz, inny build.
Raport
Dla engineeringu i dla produktu: co pęka przy jakim ruchu.
Autoscaling i limity pod ruchem, nie na slajdzie
HPA, PDB i requesty widać dopiero pod obciążeniem. Test pokazuje, czy dobijacie do limitu CPU, do puli połączeń, czy do IP w węźle. Capacity planning wychodzi z pomiaru.
Limity
Throttle CPU wygląda jak wolne API. W teście to widać.
Skala
HPA, node pool, PDB. Czy nowy pod wstaje zanim p95 ucieknie.
Sąsiedztwo
Noisy neighbor i limit namespace. Test na wspólnym klastrze ma osobne wnioski.
Koszt
Większy node group bez potrzeby jest wnioskiem FinOps, nie sukcesem testu.
Gdy pęka łącze, DNS albo peer, nie kod
ntopng i metryki krawędzi pokazują, czy test uderza w aplikację, czy w firewall, NAT albo łącze. Chaos i failover są osobną sesją, nie mieszamy ich z pierwszym pomiarem wydajności.
Ścieżka
Generator, krawędź, load balancer, pod. Każdy skok latencji ma warstwę.
Aplikacje
TLS, baza, kolejka. Klasyfikacja ruchu podpowiada, co skalować.
Failover
Osobna sesja: utrata AZ, restart bazy, przełączenie DNS.
Granica
Test DDoS to nie load test produktu. Inny cel, inny playbook.
Operacja
Od modelu ruchu do decyzji
Najpierw analityka i SLO. Potem harness i obserwacja. Na końcu soak, wniosek i ewentualny chaos.
- Model Ścieżki, udział, SLO, środowisko, dane testowe.
- Harness k6 w CI albo sesja sterowana, dashboardy, baseline.
- Pomiar Load, spike, soak. Wąskie gardło z nazwą warstwy.
- Decyzja Zmiana architektury, limitu albo kosztu. Ponowny test.
Rozmowa
Omówimy scenariusz ruchu i SLO
Na tej podstawie przygotujemy harness, sesje i raport dla architektury.
Skontaktuj się