Úvod do výkonu

Výkon databáze je rozsáhlé a složité téma, které obsahuje celou sadu komponent: databázi, síť, ovladač databáze a vrstvy přístupu k datům, jako je EF Core. Zatímco vrstvy vysoké úrovně a O/RM, jako je EF Core, výrazně zjednodušují vývoj aplikací a zlepšují udržovatelnost, můžou být někdy neprůhlené a skrývají důležité interní podrobnosti o výkonu, jako je spouštění SQL. Tato část se snaží poskytnout přehled o tom, jak dosáhnout dobrého výkonu s EF Core a jak se vyhnout běžným nástrahám, které můžou snížit výkon aplikace.

Identifikovat kritické body a měřit, měřit, měřit

Stejně jako vždy s výkonem je důležité nespěchat na optimalizaci bez dat, která ukazují problém; Jak řekl velký Donald Knuth, "Předčasně optimalizace je kořenem všeho zla". Část Diagnostika výkonu popisuje různé způsoby, jak pochopit, kde vaše aplikace tráví čas v databázové logice a jak určit konkrétní problematické oblasti. Po zjištění pomalého dotazu je možné zvážit řešení: chybí v databázi index? Měli byste vyzkoušet jiné vzory dotazování?

Vždy proveďte srovnávací testy kódu a možné alternativy sami – část diagnostika výkonu obsahuje ukázkový srovnávací test s benchmarkDotNetem, který můžete použít jako šablonu pro vlastní srovnávací testy. Nepředpokládáme, že obecné, veřejné srovnávací testy platí as-is pro váš konkrétní případ použití; Různé faktory, jako je latence databáze, složitost dotazů a skutečné objemy dat v tabulkách, můžou mít hluboký vliv na to, které řešení je nejlepší. Mnoho veřejných srovnávacích testů se například provádí v ideálních síťových podmínkách, kdy je latence databáze téměř nulová a s extrémně lehkými dotazy, které na straně databáze nevyžadují žádné zpracování (nebo vstupně-výstupní operace disku). I když jsou tyto hodnoty cenné pro porovnání režijních nákladů za běhu různých vrstev přístupu k datům, rozdíly, které odhalí, jsou obvykle zanedbatelné v reálné aplikaci, kde databáze provádí skutečnou práci a latenci databáze, je významným faktorem výkonu.

Aspekty výkonu přístupu k datům

Celkový výkon přístupu k datům je možné rozdělit do následujících širokých kategorií:

• Čistý výkon databáze. U relační databáze EF přeloží dotazy LINQ aplikace do příkazů SQL, které databáze spouští; tyto příkazy SQL mohou být spouštěny více či méně efektivně. Správný index na správném místě může mít vliv na výkon SQL nebo přepsání dotazu LINQ může generovat lepší dotaz SQL.
• Přenos síťových dat. Stejně jako u jakéhokoli síťového systému je důležité omezit množství dat, která se na drátě vrací tam a zpět. Jedná se o to, abyste při odesílání a načítání souvisejících entit zpracovávali pouze ta data, která skutečně potřebujete, a zároveň se vyhnuli tzv. „kartézské explozi“.
• Síťové zpáteční cesty. Kromě množství dat, která se pohybují tam a zpět, může být doba potřebná ke spuštění dotazu v databázi zastíněna časem, kdy pakety cestují mezi vaší aplikací a databází. Režie zpáteční cesty výrazně závisí na vašem prostředí; čím dál je databázový server, tím vyšší je latence a tím nákladnější je každý požadavek. S nástupem cloudu se aplikace stále více nacházejí dál od databáze, a "upovídané" aplikace, které dělají příliš mnoho datových přenosů, zaznamenávají snížený výkon. Proto je důležité přesně porozumět tomu, kdy vaše aplikace kontaktuje databázi, kolik cyklů provádí a jestli se dá toto číslo minimalizovat.
• Běhová režie EF Ef sám přidává do databázových operací určitou režii za běhu: EF potřebuje zkompilovat dotazy z LINQ do SQL (i když by se to mělo normálně provádět jenom jednou), sledování změn přidává určitou režii (ale může být zakázané) atd. V praxi je režie EF pro reálné aplikace pravděpodobně ve většině případů zanedbatelná, protože doba provádění dotazů v databázi a latenci sítě dominuje celkovému času; ale je důležité pochopit, co jsou vaše možnosti a jak se vyhnout určitým nástrahám.

Vědět, co se děje pod kapotou

EF umožňuje vývojářům soustředit se na obchodní logiku generováním SQL, materializací výsledků a prováděním dalších úloh. Podobně jako každá vrstva nebo abstrakce také obvykle skryje to, co se děje pod kapotou, například skutečné dotazy SQL, které se spouští. Výkon nemusí nutně být kritickým aspektem každé aplikace, ale v aplikacích, kde je, je důležité, aby vývojář porozuměl tomu, co pro ně EF dělá; prověřte odchozí dotazy SQL, sledujte zpáteční cesty a ujistěte se, že k problému N+1 nedochází atd.

Mezipaměť mimo databázi

Nejefektivnější způsob, jak pracovat s databází, je nakonec s ní vůbec nepracovat. Jinými slovy, pokud se přístup k databázi ve vaší aplikaci zobrazí jako kritický bod výkonu, může být vhodné ukládat určité výsledky do mezipaměti mimo databázi, aby se minimalizovaly požadavky. I když ukládání do mezipaměti zvyšuje složitost, je to zvlášť důležitá součást jakékoli škálovatelné aplikace: zatímco aplikační vrstvu je možné snadno škálovat přidáním dalších serverů pro zvládnutí zvýšeného zatížení, škálování databázové vrstvy je obvykle mnohem složitější.