Bevezetés a teljesítménybe

Az adatbázis teljesítménye egy hatalmas és összetett témakör, amely több összetevőből áll: az adatbázisból, a hálózatkezelésből, az adatbázis-illesztőből és az adatelérési rétegekből, például az EF Core-ból. Bár a magas szintű rétegek és az olyan O/RM-ek, mint az EF Core jelentősen leegyszerűsítik az alkalmazásfejlesztést és javítják a karbantarthatóságot, néha átlátszatlanok is lehetnek, elrejtve a teljesítmény szempontjából kritikus belső részleteket, például az SQL-t. Ez a szakasz áttekintést próbál nyújtani arról, hogyan lehet jó teljesítményt elérni az EF Core-jal, és hogyan kerülheti el azokat a gyakori buktatókat, amelyek csökkenthetik az alkalmazás teljesítményét.

Szűk keresztmetszetek azonosítása és mér, mér, mérje

A teljesítményhez hasonlóan fontos, hogy ne rohanjunk az optimalizálásba anélkül, hogy az adatok problémát mutatnak volna; ahogy a nagy Donald Knuth mondta egyszer: "A korai optimalizálás minden gonosz gyökere". A teljesítménydiagnosztikával foglalkozó szakasz a különböző módszereket ismerteti annak megértéséhez, hogy az alkalmazás hol tölt időt az adatbázislogikában, és hogyan rögzíthet konkrét problémás területeket. Ha egy lassú lekérdezést azonosítottak, a megoldások megfontolhatók: hiányzik az adatbázis indexe? Érdemes kipróbálnia más lekérdezési mintákat?

Mindig saját maga mérje fel a kódot és a lehetséges alternatívákat – a teljesítménydiagnosztika szakasz egy BenchmarkDotNet-minta-teljesítménytesztet tartalmaz, amelyet sablonként használhat saját teljesítménymutatóihoz. Ne feltételezze, hogy az általános, nyilvános teljesítménymutatók as-is vonatkoznak az adott használati esetre; Számos tényező, például az adatbázis késése, a lekérdezések összetettsége és a táblák tényleges adatmennyiségei mély hatást gyakorolhatnak arra, hogy melyik megoldás a legjobb. Például számos nyilvános teljesítménytesztet ideális hálózati körülmények között végeznek, ahol az adatbázis késése szinte nulla, és rendkívül könnyű lekérdezésekkel, amelyek alig igényelnek feldolgozást (vagy lemez I/O-t) az adatbázis oldalán. Bár ezek értékesek a különböző adatelérési rétegek futásidejű többletterheléseinek összehasonlításához, az általuk feltárt különbségek általában elhanyagolhatónak bizonyulnak egy valós alkalmazásban, ahol az adatbázis tényleges munkát végez, és az adatbázis késése jelentős teljesítménytényező.

Az adathozzáférési teljesítmény szempontjai

Az adathozzáférési teljesítmény általánosan a következő átfogó kategóriákra bontható:

• Tiszta adatbázis-teljesítmény. A relációs adatbázis esetén az EF lefordítja az alkalmazás LINQ-lekérdezéseit az adatbázis által végrehajtott SQL-utasításokra; ezek az SQL-utasítások többé-kevésbé hatékonyan futtathatók. A megfelelő helyen lévő megfelelő index nagyban befolyásolhatja az SQL teljesítményét, vagy a LINQ-lekérdezés újraírásával az EF jobb SQL-lekérdezést hozhat létre.
• Hálózati adatátvitel. Mint minden hálózati rendszer esetén, fontos korlátozni a vezetéken oda-vissza futó adatok mennyiségét. Ez magában foglalja annak biztosítását, hogy csak olyan adatokat küldjön és töltsön be, amelyekre ténylegesen szüksége lesz, de elkerülheti az úgynevezett "cartesian robbanás" hatást a kapcsolódó entitások betöltésekor.
• Hálózati körutak. Az oda-vissza adatmennyiségen túl a hálózati körutak sok időt vehetnek igénybe, mivel az adatbázisban végzett lekérdezés végrehajtási ideje eltörpülhet az alkalmazás és az adatbázis között közlekedő adatcsomagok időigényéhez képest. A roundtrip költségek nagyban függenek a környezetétől; minél távolabb van az adatbázis-kiszolgáló, annál nagyobb a késés, és annál költségesebb lesz egy-egy lekérdezés. A felhő megjelenésével az alkalmazások egyre jobban eltávolodnak az adatbázistól, és a túl sok kerekítést végrehajtó "csevegő" alkalmazások teljesítménycsökkenést tapasztalnak. Ezért fontos tisztában lenni azzal, hogy pontosan mikor lép kapcsolatba az alkalmazás az adatbázissal, hány kerekítést hajt végre, és hogy ez a szám minimalizálható-e.
• EF-futtatókörnyezet többletterhelése. Végül maga az EF némi futásidejű többletterhelést ad az adatbázis-műveletekhez: az EF-nek le kell fordítania a lekérdezéseket a LINQ-ról az SQL-re (bár ezt általában csak egyszer kell elvégezni), a változáskövetés némi többletterhelést eredményez (de le lehet tiltani) stb. A gyakorlatban a valós alkalmazások EF-re vonatkozó többletterhelése a legtöbb esetben valószínűleg elhanyagolható, mivel az adatbázisban a lekérdezések végrehajtási ideje és a hálózati késés uralja a teljes időt; de fontos megérteni, hogy mik a lehetőségek, és hogyan lehet elkerülni néhány buktatót.

Tudja, mi történik a motorháztető alatt

Az EF lehetővé teszi a fejlesztők számára, hogy az SQL generálásával, az eredmények materializálásával és más feladatok végrehajtásával összpontosítsanak az üzleti logikára. Mint minden réteg vagy absztrakció, ez is általában elrejti, ami a háttérben történik, például a tényleges SQL-lekérdezéseket. A teljesítmény nem feltétlenül minden alkalmazás kritikus eleme, de azokban az alkalmazásokban, ahol ez van, elengedhetetlen, hogy a fejlesztő megértse, mit tesz az EF a számukra: vizsgálja meg a kimenő SQL-lekérdezéseket, kövesse a kerekítéseket, hogy meggyőződjön arról, hogy az N+1 probléma nem fordul elő, stb.

Gyorsítótár az adatbázison kívül

Végül az adatbázisokkal való interakció leghatékonyabb módja az, ha egyáltalán nem kommunikál vele. Más szóval, ha az adatbázis-hozzáférés teljesítménybeli szűk keresztmetszetként jelenik meg az alkalmazásban, érdemes lehet bizonyos eredményeket az adatbázison kívül gyorsítótárazni, hogy a kérések minimálisra csökkenjenek. Bár a gyorsítótárazás összetettebbé teszi az alkalmazást, ez különösen fontos része a méretezhető alkalmazásoknak: bár az alkalmazásszint egyszerűen skálázható, ha további kiszolgálókat ad hozzá a megnövekedett terhelés kezeléséhez, az adatbázisszint skálázása általában sokkal bonyolultabb.