A CLR-integrációs architektúra teljesítménye

A következőkre vonatkozik:SQL ServerFelügyelt Azure SQL-példány

Ez a cikk néhány olyan tervezési lehetőséget ismertet, amelyek javítják az SQL Server és a .NET-keretrendszer közös nyelvi futtatókörnyezettel (CLR) való integrációjának teljesítményét.

A fordítási folyamat

Az SQL-kifejezések fordítása során, amikor egy felügyelt rutinra mutató hivatkozás történik, létrejön egy közös köztes nyelv (CIL) csonk. Ez a csonk olyan kódot tartalmaz, amely a rutinparaméterek SQL Serverről a CLR-be való visszaállítására, a függvény meghívására és az eredmény visszaadására szolgál. Ez a ragasztó kód a paraméter típusán és a paraméter irányán alapul (, , vagy hivatkozási).

A ragasztókód lehetővé teszi a típusspecifikus optimalizálást, és biztosítja az SQL Server szemantikájának hatékony érvényesítését, például a nullitást, a korlátozási aspektusokat, az értékenkénti értéket és a standard kivételkezelést. Az argumentumok pontos típusaihoz tartozó kód létrehozásával elkerülheti a kényszerítési vagy burkolóobjektum-létrehozási költségeket (az úgynevezett "boxing") a meghívás határán.

A létrehozott csonk ezután natív kódra lesz lefordítva, és az SQL Server által futtatott adott hardverarchitektúrához van optimalizálva a CLR igény szerinti (JIT) fordítási szolgáltatásaival. A JIT-szolgáltatásokat a rendszer metódusszinten hívja meg, és lehetővé teszi, hogy az SQL Server üzemeltetési környezete egyetlen összeállítási egységet hozzon létre, amely kiterjed az SQL Server és a CLR végrehajtására is. A csonk fordítása után az eredményül kapott függvénymutató lesz a függvény futásidejű implementációja. Ez a kódgenerálási módszer biztosítja, hogy a futtatáskor ne legyenek további meghívási költségek a tükrözéshez vagy a metaadatokhoz való hozzáféréshez.

Gyors áttűnések az SQL Server és a CLR között

A fordítási folyamat egy függvénymutatót eredményez, amely futtatáskor meghívható natív kódból. A skaláris értékű, felhasználó által definiált függvények esetében ez a függvényhívás soronként történik. Az SQL Server és a CLR közötti váltás költségeinek minimalizálása érdekében a felügyelt hívásokat tartalmazó utasítások indítási lépéssel azonosítják a célalkalmazás tartományát. Ez az azonosítási lépés csökkenti az egyes sorok áttűnésének költségeit.

Teljesítménnyel kapcsolatos szempontok

Az alábbi szakasz az SQL Server CLR-integrációjával kapcsolatos teljesítménybeli szempontokat foglalja össze. További információ: CLR-integráció használata az SQL Server 2005. A felügyelt kód teljesítményével kapcsolatos információkért lásd: .NET-alkalmazások teljesítményének és méretezhetőségének javítása.

Felhasználó által definiált függvények

A CLR-függvények gyorsabb meghívási útvonalat használhatnak, mint Transact-SQL felhasználó által definiált függvényeket. Emellett a felügyelt kód döntő teljesítménnyel rendelkezik a Transact-SQL szemben az eljárási kód, a számítások és a sztringek kezelése terén. A számításigényes és adathozzáférést nem végző CLR-függvények a felügyelt kódban jobban meg vannak írva. Transact-SQL függvények azonban hatékonyabban hajtják végre az adathozzáférést, mint a CLR-integráció.

Felhasználó által definiált összesítések

A felügyelt kód jelentősen felülmúlhatja a kurzoralapú összesítést. A felügyelt kód általában valamivel lassabban teljesít, mint a beépített SQL Server-összesítő függvények. Javasoljuk, hogy ha létezik natív beépített összesítő függvény, használja azt. Azokban az esetekben, amikor a szükséges összesítés natív módon nem támogatott, fontolja meg a CLR felhasználó által definiált összesítését egy kurzoralapú implementáción keresztül teljesítménybeli okokból.

Streamelő táblaértékelt függvények

Az alkalmazásoknak gyakran vissza kell adniuk egy táblát egy függvény meghívása miatt. Ilyenek például a táblázatos adatok beolvasása egy fájlból egy importálási művelet részeként, valamint a vesszővel tagolt értékek relációs ábrázolássá alakítása. Ezt általában úgy teheti meg, hogy materializálja és feltölti az eredménytáblát, mielőtt a hívó felhasználhatja. A CLR sql serverbe való integrálása egy új bővíthetőségi mechanizmust vezet be, amelyet egy streamelési táblaértékű függvénynek (STVF) nevezünk. A felügyelt STVF-ek jobban teljesítenek, mint a hasonló kiterjesztett tárolt eljárás implementációi.

Az STVF-ek felügyelt függvények, amelyek IEnumerable felületet adnak vissza. IEnumerable metódusok segítségével navigálhat az STVF által visszaadott eredményhalmazban. Az STVF meghívásakor a visszaadott IEnumerable közvetlenül csatlakozik a lekérdezési tervhez. A lekérdezési terv IEnumerable metódusokat hív meg, amikor sorokat kell beolvasnia. Ez az iterációs modell lehetővé teszi, hogy az eredmények közvetlenül az első sor létrehozása után legyenek felhasználva, ahelyett, hogy a teljes táblázat feltöltéséig várakoznak. Emellett jelentősen csökkenti a függvény meghívásával felhasznált memóriát.

Tömbök és kurzorok

Ha Transact-SQL kurzoroknak olyan adatokat kell átkelniük, amelyek tömbként könnyebben kifejezhetők, a felügyelt kód jelentős teljesítménynövekedéssel használható.

Sztringadatok

Az SQL Server karakteradatai, például a varchar, SqlString vagy SqlChars típusúak lehetnek a felügyelt függvényekben. SqlString változók a teljes érték egy példányát hozzák létre a memóriába. SqlChars változók olyan streamelési felületet biztosítanak, amellyel jobb teljesítményt és méretezhetőséget érhetünk el, ha nem hozunk létre egy példányt a teljes értékből a memóriába. Ez fontossá válik a nagyméretű objektumadatok (LOB) esetében. Emellett a kiszolgáló XML-adatai a SqlXml.CreateReader()által visszaadott streamelési felületen keresztül is elérhetők.

CLR és kiterjesztett tárolt eljárások

Azok a Microsoft.SqlServer.Server alkalmazásprogramozási felületek (API-k), amelyek lehetővé teszik, hogy a felügyelt eljárások eredményhalmazokat küldjenek vissza az ügyfélnek, jobban teljesítenek, mint a kiterjesztett tárolt eljárások által használt Open Data Services (ODS) API-k. Ezenkívül a System.Data.SqlServer API-k olyan adattípusokat támogatnak, mint például xml, varchar(max), nvarchar(max)és varbinary(max), míg az ODS API-k nem lettek kiterjesztve ezen adattípusok támogatására.

Felügyelt kóddal az SQL Server kezeli az erőforrások, például a memória, a szálak és a szinkronizálás használatát. Ennek az az oka, hogy az erőforrásokat elérhetővé tevő felügyelt API-k az SQL Server erőforrás-kezelőjén felül vannak implementálva. Ezzel szemben az SQL Server nem tekinti meg és nem szabályozza a kiterjesztett tárolt eljárás erőforrás-használatát. Ha például egy kiterjesztett tárolt eljárás túl sok processzor- vagy memóriaerőforrást használ fel, akkor ezt nem lehet észlelni vagy szabályozni az SQL Serverrel. A felügyelt kóddal azonban az SQL Server észleli, hogy egy adott szál hosszú ideje nem engedett, majd kényszeríti a feladatot a hozamra, hogy más munka ütemezhető legyen. A felügyelt kód használata tehát jobb méretezhetőséget és rendszererőforrás-használatot biztosít.

A felügyelt kód többletterhelést jelenthet a végrehajtási környezet fenntartásához és a biztonsági ellenőrzések végrehajtásához. Ez a helyzet például akkor, ha az SQL Serveren belül fut, és a felügyelt kódról a natív kódra való váltás számos áttűnésre van szükség (mivel az SQL Servernek további karbantartást kell végeznie a szálspecifikus beállításokon a natív kódra való áttéréskor és visszalépéskor). A kiterjesztett tárolt eljárások tehát jelentősen felülmúlhatják az SQL Serveren futó felügyelt kódot azokban az esetekben, amikor gyakori átmenetek vannak a felügyelt és a natív kód között.

Jegyzet

Ne dolgozzon ki új kiterjesztett tárolt eljárásokat, mert ez a funkció elavult.

Natív szerializálás felhasználó által definiált típusokhoz

A felhasználó által definiált típusok (UDT-k) bővíthetőségi mechanizmusként lettek kialakítva a skaláris típusrendszer számára. Az SQL Server a Format.Nativenevű UDT-k szerializálási formátumát implementálja. A fordítás során a rendszer megvizsgálja a típus szerkezetét, hogy létrehozhassa az adott típusdefinícióhoz testre szabott CIL-t.

Az SQL Server alapértelmezett implementációja a natív szerializálás. A felhasználó által definiált szerializálás meghív egy metódust, amelyet a típus szerzője határoz meg a szerializáláshoz. Format.Native szerializálást kell használni, ha lehetséges, a legjobb teljesítmény érdekében.

Összehasonlítható UT-k normalizálása

A relációs műveletek, például az UDT-k rendezése és összehasonlítása, közvetlenül az érték bináris ábrázolására működnek. Ez az UDT állapotának normalizált (bináris sorrendben rendezett) lemezen való tárolásával érhető el.

A normalizálásnak két előnye van:

• Ez jelentősen olcsóbbá teszi az összehasonlítási műveletet azáltal, hogy elkerüli a típuspéldány felépítését és a metódushívási többletterhelést.

• Létrehoz egy bináris tartományt az UDT számára, amely lehetővé teszi hisztogramok, indexek és hisztogramok építését a típus értékeihez.

A normalizált UDT-k tehát hasonló teljesítményprofillal rendelkeznek, mint a natív beépített típusok olyan műveletek esetében, amelyek nem járnak metódushívással.

Méretezhető memóriahasználat

Annak érdekében, hogy a felügyelt szemétgyűjtés jól teljesíthessen és skálázható legyen az SQL Serveren, kerülje a nagy, egyszeri lefoglalást. A 88 kilobájtnál (KB) nagyobb foglalások a Nagy objektum halomra kerülnek, ami miatt a szemétgyűjtés végrehajtása és skálázása rosszabb, mint sok kisebb foglalás. Ha például nagy többdimenziós tömböt kell lefoglalnia, jobb, ha egy szaggatott (pontozott) tömböt foglal le.

Kapcsolódó tartalom

• clr felhasználó által definiált típusok