Výkonnostní testování API a mikroslužeb
Výkonnostní testování API měří, jak se při zátěži chovají rozhraní, přes která vaše systémy komunikují – bez prohlížeče a vykreslování stránky. Pomáhá oddělit chování backendu od uživatelského rozhraní a zúžit hledání problémů, jako jsou pomalé databázové dotazy, vyčerpaný pool spojení nebo přetížená integrace.
Běžný problém: rozhraní skrývá příčinu zpomalení
Test přes uživatelské rozhraní je užitečný pro ověření celé zákaznické cesty, ale spojuje více vrstev najednou. Prohlížeč přidává vykreslování, načítání skriptů a síťové požadavky, takže ze samotného výsledku nemusí být jasné, zda zpomalení vzniklo v API, nebo při sestavování stránky.
U mikroslužeb může jedna služba volat několik dalších a zpomalení v řetězci se navenek projeví jako „pomalý web“. Měření vybraných API společně s trasováním a systémovými metrikami pomáhá určit, kterou část řetězce prozkoumat jako první.
Jak měřit výkon přímo na API
Nejprve můžeme samostatně zatížit vybraná API rozhraní, abychom změřili jejich chování bez režie prohlížeče. Poté má smysl připravit také realistickou směs volání, která odpovídá skutečnému provozu. Samostatné měření ukáže, které volání se při dané zátěži zpomaluje; příčinu je nutné potvrdit údaji z aplikace a infrastruktury.
Měříme odezvy v percentilech (p95, p99), chybovost i propustnost. Pokud jsou dostupné metriky serveru, databáze a jednotlivých služeb, porovnáváme je na jedné časové ose. Tím lze zúžit hledání úzkého místa na konkrétní endpoint, dotaz, pool spojení nebo závislou službu.
Podle rizika vybíráme load, stress nebo spike test – jiná otázka platí pro očekávaný provoz a jiná pro náhlý nápor. Scénáře v k6 nebo Locustu mohou žít v repozitáři a vybrané, přiměřeně rozsáhlé kontroly lze zapojit také do CI. Rozsáhlejší měření se obvykle spouštějí v kontrolovaném prostředí a čase. Jde o stejná API, která pokrýváme funkčními testy – zde však měříme jejich chování při zátěži.
Co vám měření API přinese
- Užší okruh pravděpodobných příčin – konkrétní endpoint, dotaz nebo službu namísto obecného „web je pomalý“.
- Měření backendu bez režie prohlížeče, které doplňuje test celé uživatelské cesty.
- Včas pojmenovaná kapacitní rizika v API, databázi a integracích.
Další krok
Vyberte API rozhraní, která jsou důležitá pro klíčový proces nebo již vykazují pomalé odezvy. Doplňte očekávanou zátěž, limity odezvy a chybovosti a dostupné systémové metriky. Z toho lze připravit měření, které odpoví na konkrétní kapacitní otázku.