Případová studie: Izolace problému s výkonem (C#, Visual Basic, F#)

Tato případová studie ukazuje, jak pomocí nástrojů pro profilaci sady Visual Studio identifikovat a vyřešit problémy s výkonem v ukázkové aplikaci ASP.NET. Porovnání nástrojů pro profilaci najdete v části Který nástroj mám zvolit?

Naučíte se:

• Použití nástrojů pro profilaci sady Visual Studio k analýze výkonu aplikace
• Jak interpretovat data profilace za účelem nalezení kritických bodů
• Praktické strategie optimalizace kódu pomocí čítačů .NET, počtu volání a dat časování

Tyto techniky použijte ke zlepšení vlastních aplikací.

Izolace problému s výkonem v případové studii

Ukázková ASP.NET aplikace spouští dotazy na simulovanou databázi a je založená na ukázce diagnostiky.

Klíčové příznaky výkonu:

• Nízké využití procesoru: Procesor není kritickým bodem.
• Vysoký počet vláken ThreadPool: Počet vláken se nepřetržitě zvyšuje, což označuje vyčerpaný fond vláken.
• Pomalá odezva aplikace: Aplikace reaguje pomalu kvůli nedostatku dostupných vláken.

Tato případová studie používá nástroje pro profilaci sady Visual Studio k určení a řešení těchto problémů, což vám pomůže zrychlit a zefektivnit váš kód.

Výzva

Řešení těchto problémů zahrnuje několik problémů:

• Diagnostika kritických bodů: Nízké využití procesoru s nízkým výkonem může mít několik příčin. Efektivní použití nástrojů pro profilaci a interpretace jejich výstupu je nezbytné.
• Omezení znalostí a prostředků: Profilace a optimalizace vyžadují specifické dovednosti a zkušenosti, které nemusí být vždy dostupné.

Strategický přístup, který kombinuje nástroje pro profilaci, technické znalosti a pečlivé testování, je klíčem k překonání těchto výzev.

Strategie

Tady je základní pohled na přístup v této případové studii:

• Začněte monitorováním metrik čítačů .NET při shromažďování dat o výkonu. Dobrým výchozím bodem je nástroj .NET Counters sady Visual Studio.
• Pokud chcete získat podrobnější přehledy, shromážděte data pomocí dalších nástrojů pro profilaci, jako je nástroj Instrumentace pro počet volání a časová data.

Shromažďování dat vyžaduje následující úlohy:

• Nastavte aplikaci na vydání buildu.
• Vyberte nástroj Čítače .NET v profileru výkonu (Alt+F2).
• Spusťte aplikaci a shromážděte záznam.

Kontrola čítačů výkonu

Při spouštění aplikace sledujeme čítače v nástroji Čítače .NET. U počátečních šetření je potřeba mít přehled o několika klíčových metrikách:

• CPU Usage. Podívejte se na tento čítač a zjistěte, jestli dochází k problému s výkonem při vysokém nebo nízkém využití procesoru. Může to být vodítko pro konkrétní typy problémů s výkonem. Například:
  • Při vysokém využití procesoru použijte nástroj Využití procesoru k identifikaci oblastí, ve kterých můžeme optimalizovat kód. Kurz k tomuto tématu najdete v případové studii: Příručka pro začátečníky k optimalizaci kódu.
  • Při nízkém využití procesoru použijte nástroj Instrumentation k identifikaci počtu volání a průměrného času funkce na základě hodinového času. To může pomoct s identifikací problémů, jako jsou kolize nebo hladovění fondu vláken.
• Allocation Rate. U webové aplikace, která obsluhuje požadavky, by měla být rychlost poměrně stabilní.
• GC Heap Size. Sledujte tento čítač, abyste zjistili, jestli se využití paměti neustále zvětšuje a potenciálně uniká. Pokud se zdá, že je vysoká, použijte jeden z nástrojů pro využití paměti.
• Threadpool Thread Count. U webové aplikace, která obsluhuje požadavky, sledujte tento čítač, abyste zjistili, jestli se počet vláken zůstává stabilní nebo roste stabilně.

Tady je příklad znázorňující, jak je CPU Usage nízký, zatímco ThreadPool Thread Count je relativně vysoká.

Stále rostoucí počet vláken s nízkým využitím procesoru může být indikátorem hladovění fondu vláken. Fond vláken je nucen neustále vytvářet nové vlákna. K hladovění fondu vláken dochází v případě, že fond nemá žádná dostupná vlákna pro zpracování nových pracovních položek a často způsobuje, že aplikace reagují pomalu.

Vzhledem k nízkému využití procesoru, relativně vysokému počtu vláken a teorii možného případu vyčerpání fondu vláken, přepněte na použití nástroje Instrumentation.

Zkoumání počtu volání a dat časování

Pojďme se podívat na trasování z nástroje pro monitorování, abychom zjistili, zda můžeme zjistit, co se děje s vlákny.

Po shromáždění trasování pomocí nástroje Instrumentace a jeho načtení do Visual Studio nejprve zkontrolujeme počáteční stránku sestavy .diagsession , která zobrazuje souhrnná data. V rámci shromážděného trasování použijeme odkaz Otevřít podrobnosti v sestavě a pak vybereme Flame Graph.

Vizualizace Flame Graphu ukazuje, že za významnou část doby běhu aplikace zodpovídá funkce QueryCustomerDB (zobrazená žlutě).

Klikněte pravým tlačítkem myši na funkci QueryCustomerDB a zvolte Zobrazit ve stromu volání.

Cesta kódu s nejvyšším využitím procesoru v aplikaci se nazývá hot path. Ikona plamene horké cesty () vám může pomoct rychle identifikovat problémy s výkonem, které by mohly být vylepšeny.

V zobrazení Stromu volání vidíte, že horká cesta obsahuje funkci QueryCustomerDB, která odkazuje na potenciální problém s výkonem.

Vzhledem k času stráveného v jiných funkcích jsou hodnoty Self a Avg Self pro funkci QueryCustomerDB velmi vysoké. Na rozdíl od Total a Avg Totalhodnoty Self vylučují čas strávený v jiných funkcích, takže je to vhodné místo pro vyhledání výkonového úzkého místa.

Spropitné

Pokud hodnoty byly relativně nízké místo vysoké, pravděpodobně byste se chtěli podívat na skutečné dotazy volané funkcí QueryCustomerDB.

Poklikejte na funkci QueryCustomerDB a zobrazte zdrojový kód funkce.

public ActionResult<string> QueryCustomerDB()
{
    Customer c = QueryCustomerFromDbAsync("Dana").Result;
    return "success:taskwait";
}

Děláme trochu výzkumu. Alternativně můžeme ušetřit čas a nechat Copilot udělat výzkum za nás.

Pokud používáme Copilot , vyberte Požádat Copilot z místní nabídky a zadejte následující otázku:

Can you identify a performance issue in the QueryCustomerDB method?

Spropitné

Příkazy lomítka, jako je /optimize, můžete použít k tomu, abyste vytvářeli vhodné otázky pro Copilot.

Copilot nám říká, že tento kód volá asynchronní rozhraní API bez použití příkazu Await. Toto je vzor kódu synchronizace přes asynchronní, což je běžná příčina hladovění fondu vláken a může blokovat vlákna.

Pokud chcete problém vyřešit, použijte příkaz await. V tomto příkladu poskytuje Copilot následující návrh kódu spolu s vysvětlením.

public async Task<ActionResult<string>> QueryCustomerDB()
{
    Customer c = await QueryCustomerFromDbAsync("Dana");
    return "success:taskwait";
}

Pokud se zobrazí problémy s výkonem související s databázovými dotazy, můžete pomocí nástroje Database zjistit, jestli jsou určitá volání pomalejší. Tato data můžou znamenat příležitost k optimalizaci dotazů. Kurz, který ukazuje, jak pomocí databázového nástroje prozkoumat problém s výkonem, najdete v případové studii: Příručka začátečníka k optimalizaci kódu. Nástroj Database podporuje .NET Core s ADO.NET nebo Entity Framework Core.

Pokud chcete získat vizualizace ve Visual Studiu pro chování jednotlivých vláken, můžete při ladění použít okno Paralelní zásobníky. Toto okno zobrazuje jednotlivá vlákna spolu s informacemi o vláknech čekajících, vláknech, na kterých čekají, a deadlocích.

Další informace o hladovění fondu vláken naleznete v tématu Zjišťování hladovění fondu vláken.

Další kroky

Následující články a blogové příspěvky obsahují další informace, které vám pomůžou efektivně používat nástroje pro výkon sady Visual Studio.

• Případová studie: Příručka pro začátečníky k optimalizaci kódu
• případová studie : Dvojitý výkon za méně než 30 minut
• vylepšení výkonu sady Visual Studio pomocí nového nástroje instrumentace

Související obsah

• Který nástroj mám použít?
• Analýza využití procesoru v Profileru výkonu
• Instrumentace aplikace .NET
• Analýza výkonu databáze
• První seznámení s profilací