Optimalizace výkonu pro distribuovanou aplikaciPerformance tuning a distributed application

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.In this series, we walk through several cloud application scenarios, showing how a development team used load tests and metrics to diagnose performance issues. 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í.These articles are based on actual load testing that we performed when developing example applications. Kód pro jednotlivé scénáře je k dispozici na GitHubu.The code for each scenario is available on GitHub.

Scénáře:Scenarios:

Co je výkon?What is performance?

Výkon se často měří propustností, dobou odezvy a dostupností.Performance is frequently measured in terms of throughput, response time, and availability. Výkonnostní cíle by měly vycházet z obchodních operací.Performance targets should be based on business operations. Ú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.Customer-facing tasks may have more stringent requirements than operational tasks such as generating reports.

Definujte cílovou úroveň služeb (SLO), která definuje výkonnostní cíle pro jednotlivé úlohy.Define a service level objective (SLO) that defines performance targets for each workload. Zpravidla toho dosáhnete rozdělením výkonnostních cílů do sady klíčových ukazatelů výkonu (KPI), například:You typically achieve this by breaking a performance target into a set of Key Performance Indicators (KPIs), such as:

  • Latence nebo doba odezvy konkrétních požadavkůLatency or response time of specific requests
  • Počet požadavků provedených za sekunduThe number of requests performed per second
  • Rychlost, s jakou systém generuje výjimkyThe rate at which the system generates exceptions.

Výkonnostní cíle by měly explicitně zahrnovat cílové zatížení.Performance targets should explicitly include a target load. Platí také, že ne všichni uživatelé budou mít přesně stejnou úroveň výkonu, i když přistupují k systému současně a provádějí stejnou práci.Also, not all users will receive exactly the same level of performance, even when accessing the system simultaneously and performing the same work. Cílová úroveň služeb by se proto měla vyjadřovat v percentilech.So an SLO should be framed in terms of percentiles.

Příklad cílové úrovně služeb: „Odpověď na požadavky klientů bude v rámci 500 ms (pro P90), a to při zatížení až 25 tis. požadavků za sekundu.“An example SLO for might be: "Client requests will have a response within 500 ms @ P90, at loads up to 25 K requests/second."

Problémy s optimalizací výkonu distribuovaného systémuChallenges of performance tuning a distributed system

V distribuované aplikaci může být diagnostika potíží s výkonem obzvlášť náročná.It can be especially challenging to diagnose performance issues in a distributed application. Příklady problémů, které je potřeba řešit:Some of the challenges are:

  • Jedna obchodní transakce nebo operace obvykle zahrnuje několik komponent systému.A single business transaction or operation typically involves multiple components of the system. Zajištění holistického komplexního náhledu na samostatnou operaci může být velmi náročné.It can be hard to get a holistic end-to-end view of a single operation.

  • Spotřeba prostředků se distribuuje napříč několika uzly.Resource consumption is distributed across multiple nodes. K zajištění konzistentního náhledu je potřeba agregovat protokoly a metriky na jednom místě.To get a consistent view, you need to aggregate logs and metrics in one place.

  • Cloud nabízí elastické škálování.The cloud offers elastic scale. 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.Autoscaling is an important technique for handling spikes in load, but it can also mask underlying issues. Někdy je také těžké zjistit, které komponenty potřebují škálování a kdy.Also, it can be hard to know which components need to scale and when.

  • Kaskádová selhání mohou způsobit to, že se základní problém projeví někde výš.Cascading failures can cause failures upstream of the root problem. Následkem toho se první známka problému může projevit v komponentě, která není příčinou daného problému.As a result, the first signal of the problem may appear in a different component than the root cause.

Obecné osvědčené postupyGeneral best practices

Optimalizace výkonu je umění i věda, ale systematickým přístupem se dá víc přiblížit vědě.Performance tuning is both an art and a science, but it can be made closer to science by taking a systematic approach. Tady jsou některé osvědčené postupy:Here are some best practices:

  • Povolte telemetrii pro shromažďování metrik.Enable telemetry to collect metrics. Instrumentujte váš kód.Instrument your code. Využijte osvědčené postupy pro monitorování.Follow best practices for monitoring. Použijte korelační trasování, abyste mohli zobrazit všechny kroky v transakci.Use correlated tracing so that you can view all the steps in a transaction.

  • Monitorujte percentily 90/95/99, ne jenom průměr.Monitor the 90/95/99 percentiles, not just average. Průměr může maskovat odlehlé hodnoty.The average can mask outliers. Důležitá je také vzorkovací frekvence pro metriky.The sampling rate for metrics also matters. Pokud je vzorkovací frekvence příliš nízká, může skrýt špičky nebo odlehlé hodnoty, které mohou indikovat problémy.If the sampling rate is too low, it can hide spikes or outliers that might indicate problems.

  • Kritické body řešte jeden po druhém.Attack one bottleneck at a time. Vytvořte si hypotézu a otestujte ji tak, že vždycky změníte jenom jednu proměnnou.Form a hypothesis and test it by changing one variable at a time. Odstranění jednoho kritického bodu často odhalí další následné nebo naopak dřívější kritické body.Removing one bottleneck will often uncover another bottleneck further upstream or downstream.

  • Chyby a opakování mohou mít velký dopad na výkon.Errors and retries can have a large impact on performance. Pokud vidíte, že vás omezují back-endové služby, využijte horizontální rozšíření kapacity nebo se pokuste optimalizovat využití (například vyladěním databázových dotazů).If you see that you are being throttled by backend services, scale out or try to optimize usage (for example by tuning database queries).

  • Hledejte běžné antivzory výkonu.Look for common performance anti-patterns.

  • Hledejte příležitosti pro paralelizaci.Look for opportunities to parallelize. Dvěma běžnými zdroji kritických bodů jsou fronty zpráv a databáze.Two common sources of bottlenecks are message queues and databases. V obou případech pomáhá horizontální dělení.In both cases, sharding can help. Další informace najdete v tématu věnovaném horizontálnímu, vertikálnímu a funkčnímu dělení dat.For more information, see Horizontal, vertical, and functional data partitioning. Hledejte horké oddíly, které mohou indikovat nevyvážené zatížení čtení nebo zápisu.Look for hot partitions that might indicate imbalanced read or write loads.

Další krokyNext steps

Přečíst scénáře optimalizace výkonuRead the performance tuning scenarios