Optimalizace výkonu pro distribuovanou aplikaci
V této sérii si projdeme několik scénářů cloudových aplikací, které ukazují, jak vývojový tým využil zátěžové testy a metriky pro diagnostiku problémů s výkonem. Tyto články vycházejí ze skutečného zátěžového testování, které jsme provedli při vývoji ukázkových aplikací. Kód pro jednotlivé scénáře je k dispozici na GitHubu.
Scénáře:
Co je výkon?
Výkon se často měří propustností, dobou odezvy a dostupností. Výkonnostní cíle by měly vycházet z obchodních operací. Úlohy určené pro zákazníky mohou mít přísnější požadavky než provozní úlohy, jako je třeba generování sestav.
Definujte cílovou úroveň služeb (SLO), která definuje výkonnostní cíle pro jednotlivé úlohy. Tohoto cíle obvykle dosáhnete rozdělením cíle výkonu do sady klíčových ukazatelů výkonu (KPI), jako jsou:
- Latence nebo doba odezvy konkrétních požadavků
- Počet požadavků provedených za sekundu
- Rychlost, s jakou systém generuje výjimky
Výkonnostní cíle by měly explicitně zahrnovat cílové zatížení. Také ne všichni uživatelé obdrží přesně stejnou úroveň výkonu, i když přistupují k systému současně a provádějí stejnou práci. Cílová úroveň služeb by se proto měla vyjadřovat v percentilech.
Příkladem cíle úrovně služby může být: "Požadavky klientů mají odpověď v rozsahu 500 ms @ P90 při zatížení až 25 K požadavků za sekundu."
Problémy s optimalizací výkonu distribuovaného systému
V distribuované aplikaci může být diagnostika potíží s výkonem obzvlášť náročná. Příklady problémů, které je potřeba řešit:
Jedna obchodní transakce nebo operace obvykle zahrnuje několik komponent systému. Zajištění holistického komplexního náhledu na samostatnou operaci může být velmi náročné.
Spotřeba prostředků se distribuuje napříč několika uzly. K zajištění konzistentního náhledu je potřeba agregovat protokoly a metriky na jednom místě.
Cloud nabízí elastické škálování. Automatické škálování je důležitou metodou pro zpracování provozních špiček, ale může také zamaskovat základní problémy. Někdy je také těžké zjistit, které komponenty potřebují škálování a kdy.
Úlohy se často neš škálují napříč jádry nebo vlákny. Je důležité porozumět požadavkům úloh a podívat se na lépe optimalizované velikosti. Některé velikosti nabízejí omezená jádra a zakázání hyperthreadingu, aby se zlepšily úlohy orientované na jedno jádro a na jádro licencované úlohy.
Kaskádová selhání mohou způsobit to, že se základní problém projeví někde výš. Následkem toho se první známka problému může projevit v komponentě, která není příčinou daného problému.
Obecné osvědčené postupy
Optimalizace výkonu je umění i věda, ale systematickým přístupem se dá víc přiblížit vědě. Tady jsou některé osvědčené postupy:
Povolte telemetrii pro shromažďování metrik. Instrumentujte váš kód. Využijte osvědčené postupy pro monitorování. Použijte korelační trasování, abyste mohli zobrazit všechny kroky v transakci.
Monitorujte percentily 90/95/99, ne jenom průměr. Průměr může maskovat odlehlé hodnoty. Důležitá je také vzorkovací frekvence pro metriky. Pokud je vzorkovací frekvence příliš nízká, může skrýt špičky nebo odlehlé hodnoty, které mohou indikovat problémy.
Kritické body řešte jeden po druhém. Vytvořte si hypotézu a otestujte ji tak, že vždycky změníte jenom jednu proměnnou. Odstranění jednoho kritického bodu často odhalí další následné nebo naopak dřívější kritické body.
Chyby a opakování mohou mít velký dopad na výkon. Pokud zjistíte, že back-endové služby omezují váš systém, škálujte kapacitu nebo se pokuste optimalizovat využití (například laděním databázových dotazů).
Hledejte běžné antivzory výkonu.
Hledejte příležitosti pro paralelizaci. Dvěma běžnými zdroji kritických bodů jsou fronty zpráv a databáze. V obou případech pomáhá horizontální dělení. Další informace najdete v tématu věnovaném horizontálnímu, vertikálnímu a funkčnímu dělení dat. Hledejte horké oddíly, které mohou indikovat nevyvážené zatížení čtení nebo zápisu.
Další kroky
Přečíst scénáře optimalizace výkonu