Nejčastější úzká místa webových aplikací a API
Systém se zpomalil, zákazníci čekají déle a tým potřebuje rozhodnout, zda pomůže výkonnější server, změna aplikace nebo úprava databáze. Bez měření lze snadno investovat do řešení, které pouze zmírní příznak.
Nedostatečně dimenzovaná infrastruktura je jednou z možných příčin. Zpomalení však může vzniknout také v databázovém dotazu, nedostatečném počtu spojení, volání externí služby nebo jiném konkrétním místě, které při vyšší zátěži začne omezovat celý systém.
Běžné problémy: kde se systém obvykle zpomaluje
Pomalé SQL dotazy. Dotaz, který je při malém objemu dat rychlý, může u větší tabulky trvat podstatně déle. Při souběžném spuštění mnoha stejných dotazů potom může zatížit databázi a zpomalit aplikaci.
Chybějící nebo nevhodné indexy. Databáze může u některých dotazů procházet velkou část tabulky, přestože by vhodný index vyhledávání urychlil. Index však není bezplatnou opravou: zabírá místo a může zpomalit zápis. Návrh je proto nutné ověřit plánem provedení dotazu a měřením po změně.
N+1 dotazy. Aplikace načte seznam objednávek jedním dotazem a poté pro každou z nich odešle další dotaz na detail. U dvaceti položek na stránce tak provede dvacet jedna dotazů. Při zátěži může jejich součet databázi výrazně zatížit, přestože jednotlivé dotazy vypadají rychle.
Vyčerpaný pool databázových spojení. Aplikace má omezený počet spojení k databázi. Když jsou všechna obsazená, další požadavky čekají ve frontě, i když některé systémové metriky zatím neukazují vysoké vytížení. Příčinou může být nevhodná velikost poolu, dlouhé dotazy nebo spojení, která se neuvolňují včas.
Nedostatečně dimenzovaná infrastruktura. Procesor, paměť, síť nebo disk mohou být skutečným úzkým místem. Rozhodnutí o škálování má vycházet z měření, které ukáže, který prostředek dosahuje svého limitu a jak to souvisí se zhoršením odezvy nebo chybovosti.
Jak najít skutečnou příčinu
Zásadní je, že nesledujeme pouze výsledek testu. Metriky ze zátěžového testu – odezvy v percentilech, chybovost a propustnost – sledujeme společně s metrikami serveru na jedné časové ose.
Společná časová osa pomáhá hledat souvislosti. Pokud společně s hodnotou p95 vzroste také počet požadavků čekajících na databázové spojení, vzniká důvodná hypotéza o problému v této oblasti. Časová shoda však sama o sobě příčinu nedokazuje; je nutné ji potvrdit logy, konfigurací, profilováním nebo opakovaným testem po cílené změně.
Scénáře proto stavíme podle důležitých zákaznických cest, nikoli pouze jako opakování jedné adresy. Domovská stránka může zatěžovat jiné části systému než vyhledávání, košík nebo platba. Zvolený scénář tak přímo ovlivňuje, která úzká místa se v testu projeví.
Postupně zvyšujeme zátěž, sledujeme dohodnuté limity a zaznamenáme bod, ve kterém se zhorší odezvy nebo chybovost. Systémové metriky potom pomáhají určit zdroj, který je třeba prozkoumat jako první.
Co vám pojmenované úzké místo přinese
Získáte naměřené příznaky, pravděpodobnou příčinu a plán jejího ověření. Doporučení lze seřadit podle rizika, očekávaného přínosu a náročnosti.
Cílená úprava dotazu, indexu nebo konfigurace může být levnější než škálování infrastruktury, ale vhodné řešení závisí na potvrzené příčině a provozních požadavcích. Pokud problém způsobuje například N+1 dotaz, může větší server pouze posunout kapacitní hranici, aniž by odstranil neefektivní chování.
Po zapracování doporučení lze test zopakovat a ověřit, zda se kapacitní hranice posunula.
Další krok
Zaznamenejte scénář, při kterém systém zpomaluje, čas problému a dostupné metriky aplikace, databáze a infrastruktury. Tyto údaje pomohou připravit cílený test a odlišit pravděpodobné příčiny od náhodné časové shody.