Megosztás a következőn keresztül:

A feltöltések és letöltések teljesítményének finomhangolása a .NET-tel

Amikor egy alkalmazás az Azure Storage .NET-ügyfélkódtárával továbbít adatokat, számos tényező befolyásolhatja a sebességet, a memóriahasználatot, sőt a kérés sikerességét vagy sikertelenségét is. Az adatátviteli teljesítmény és a megbízhatóság maximalizálása érdekében fontos, hogy proaktív módon konfigurálja az ügyfélkódtár-átviteli lehetőségeket az alkalmazás által futtatott környezet alapján.

Ez a cikk az adatátviteli beállítások finomhangolásának számos szempontját ismerteti, és az útmutató minden olyan API-ra vonatkozik, amely paraméterként elfogad StorageTransferOptions . Megfelelő hangolás esetén az ügyfélkódtár hatékonyan elosztja az adatokat több kérelem között, ami jobb működést, memóriahasználatot és hálózati stabilitást eredményezhet.

Teljesítményhangolás a StorageTransferOptions használatával

A StorageTransferOptions értékeinek megfelelő finomhangolása kulcsfontosságú az adatátviteli műveletek megbízható teljesítményéhez. A tárolási átadások több altranszferre vannak bontva a struktúra egy példányában meghatározott tulajdonságértékek alapján. A maximálisan támogatott átvitel mérete művelettől és szolgáltatásverziótól függően változik, ezért a korlátok meghatározásához mindenképpen ellenőrizze a dokumentációt. A Blob Storage átviteli méretkorlátjairól további információt a Blob Storage céljainak méretezése című témakörben talál.

Az alkalmazás igényeinek megfelelően az alábbi tulajdonságok StorageTransferOptions hangolhatók:

Feljegyzés

Bár a StorageTransferOptions szerkezet null értékű értékeket tartalmaz, az ügyfélkódtárak minden egyes értékhez alapértelmezett értékeket használnak, ha nincsenek megadva. Ezek az alapértelmezett értékek általában az adatközponti környezetekben teljesítenek, de valószínűleg nem alkalmasak otthoni fogyasztói környezetekhez. A rosszul hangolt StorageTransferOptions túl hosszú műveleteket, vagy akár időtúllépéseket is eredményezhet. A legjobb, ha proaktív módon teszteli az értékeket StorageTransferOptions, és az alkalmazás és a környezet igényeinek megfelelően finomhangolhatja őket.

Kezdőátviteli méret

Az InitialTransferSize az első tartománykérés mérete bájtban. A HTTP-tartománykérelem egy részleges kérelem, amelynek méretét ebben az esetben határozták meg InitialTransferSize . Az ennél kisebb blobok egyetlen kérelemben lesznek átadva. Az ennél nagyobb blobok továbbra is nagy méretű tömbökben MaximumTransferSizelesznek átadva.

Fontos megjegyezni, hogy a megadott MaximumTransferSizeérték nem korlátozza a megadott InitialTransferSizeértéket. InitialTransferSize Külön méretkorlátozást határoz meg a teljes művelet egyszerre történő végrehajtására irányuló kezdeti kéréshez, altranszferek nélkül. Gyakran előfordul, hogy szeretné, ha InitialTransferSize legalább akkorára nőne, mint a meghatározott érték, ha nem nagyobbra. Az adatátvitel méretétől függően ez a megközelítés hatékonyabb lehet, mivel az átvitel egyetlen kéréssel fejeződik be, és elkerüli a több kérelem többletterhelését.

Ha nem biztos abban, hogy melyik érték a legjobb a helyzethez, akkor a biztonságos lehetőség az, ha ugyanazt az értéket állítja be InitialTransferSize , amelyet a rendszer használ MaximumTransferSize.

Feljegyzés

Amikor egy BlobClient objektumot használ, egy, a InitialTransferSize méretnél kisebb blob feltöltése a Put Blob használatával történik, ahelyett, hogy Put Block-ot használnánk.

Maximális konkurencia

MaximumPárhuzamosság a párhuzamos átvitel során használható munkavégzők maximális száma. Jelenleg csak az aszinkron műveletek képesek párhuzamosítani az átviteleket. A szinkron műveletek figyelmen kívül hagyják ezt az értéket, és sorrendben működnek.

Ennek az értéknek a hatékonysága a .NET-ben a kapcsolatkészlet korlátainak függvénye, amely bizonyos esetekben alapértelmezés szerint korlátozhatja a teljesítményt. Az alábbi kóddal 100-ra növelheti az alapértelmezett kapcsolati korlátot (amely általában egy ügyfélkörnyezetben kettő, kiszolgálókörnyezetben tíz). Az értéket általában körülbelül az alkalmazás által használt szálak számának megfelelő értékre kell állítania. A kapcsolatok megnyitása előtt állítsa be a kapcsolatkorlátot.

ServicePointManager.DefaultConnectionLimit = 100; //(Or More)

A .NET-keretrendszer kapcsolatkészletkorlátairól a .NET-keretrendszer kapcsolatkészlet korlátairól és a .NET-hez készült új Azure SDK-ról olvashat bővebben.

További információ: ThreadPool.SetMinThreads metódus.

Maximális Átvitel Mérete

A MaximumTransferSize az átvitel maximális hossza bájtban. Ahogy korábban említettük, ez az érték nem korlátozza a korlátot InitialTransferSize, amely nagyobb lehet, mint MaximumTransferSize.

Az adatok hatékony mozgásának fenntartása érdekében előfordulhat, hogy az ügyfélkönyvtárak nem mindig érik el az MaximumTransferSize értéket minden átvitel esetében. A művelettől függően az átviteli méret maximális támogatott értéke eltérő lehet. Például a blokkblobok, amelyek a "Put Block" műveletet hajtják végre egy 2019-12-12-es vagy újabb szolgáltatásverzióval, maximális blokkmérete 4000 MiB. A Blob Storage átviteli méretkorlátairól további információt a Blob Storage méretezési céljainak diagramjában talál.

Mintakód

Az ügyfélkódtár tartalmaz olyan túlterheléseket a Upload és UploadAsync metódusokhoz, amelyek elfogadnak egy StorageTransferOptions-példányt a BlobUploadOptions paraméter részeként. Hasonló túlterhelések léteznek a DownloadTo és DownloadToAsync metódusokhoz, amelyek a BlobDownloadToOptions paramétert használják.

Az alábbi példakód bemutatja, hogyan definiálhat értékeket egy StorageTransferOptions példányhoz, és hogyan adhat meg paraméterként UploadAsyncezeket a konfigurációs beállításokat. Az ebben a mintában megadott értékek nem javaslatok. Ezeknek az értékeknek a megfelelő finomhangolásához figyelembe kell vennie az alkalmazás adott igényeit.

// Specify the StorageTransferOptions
BlobUploadOptions options = new BlobUploadOptions
{
    TransferOptions = new StorageTransferOptions
    {
        // Set the maximum number of parallel transfer workers
        MaximumConcurrency = 2,

        // Set the initial transfer length to 8 MiB
        InitialTransferSize = 8 * 1024 * 1024,

        // Set the maximum length of a transfer to 4 MiB
        MaximumTransferSize = 4 * 1024 * 1024
    }
};

// Upload data from a stream
await blobClient.UploadAsync(stream, options);

Ebben a példában a párhuzamos átvitelű feldolgozók számát 2-es értékre állítjuk a MaximumConcurrency tulajdonság használatával. Ez a konfiguráció egyszerre legfeljebb két kapcsolatot nyit meg, így a feltöltés párhuzamosan történik. A kezdeti HTTP-tartománykérés legfeljebb 8 MiB adat feltöltését kísérli meg a InitialTransferSize tulajdonság által meghatározott módon. Vegye figyelembe, hogy InitialTransferSize csak kereshető stream használata esetén vonatkozik a feltöltésekre. Ha a blob mérete kisebb, mint 8 MiB, csak egyetlen kérés szükséges a művelet végrehajtásához. Ha a blob mérete nagyobb, mint 8 MiB, az összes további átviteli kérelem maximális mérete 4 MiB, amelyet a MaximumTransferSize tulajdonsággal állítottunk be.

A szálak minimális számának növelése

Ha szinkron hívásokat és aszinkron feladatokat használ, érdemes lehet növelni a szálak számát a szálkészletben:

ThreadPool.SetMinThreads(100,100); //(Determine the right number for your application)

A feltöltések teljesítményével kapcsolatos szempontok

A feltöltés során a Storage klienskönyvtárak egy adott feltöltési adatfolyamot több résztöltésre osztanak fel a StorageTransferOptions példányban meghatározott értékek alapján. Minden alfeltöltéshez saját dedikált hívás tartozik a REST-művelet végrehajtására. Objektum BlobClient vagy BlockBlobClient objektum esetén ez a művelet a Blokk elhelyezése. Objektum DataLakeFileClient esetén ez a művelet az Adatok hozzáfűzése. A Storage-ügyfélkódtár párhuzamosan kezeli ezeket a REST-műveleteket (az átviteli lehetőségektől függően) a teljes feltöltés befejezéséhez.

Attól függően, hogy a feltöltési stream kereshető vagy nem kereshető, az ügyfélkódtár a pufferelést és InitialTransferSize más módon kezeli a következő szakaszokban leírtak szerint. A kereshető streamek olyan streamek, amelyek támogatják a streamek aktuális pozíciójának lekérdezését és módosítását. A .NET-beli streamekről a Stream-osztály referenciájában talál további információt.

Feljegyzés

A blokkblobok maximális blokkszáma 50 000 blokk. A blokkblob maximális mérete tehát 50 000-szerese MaximumTransferSize.

Pufferelés feltöltések során

A Storage REST-réteg nem támogatja a REST feltöltési művelet felvételét ott, ahol abbahagyta; az egyes átvitelek befejeződnek vagy elvesznek. A nem kereshető streamfeltöltések rugalmasságának biztosítása érdekében a Storage-ügyfélkódtárak pufferelik az egyes REST-hívások adatait a feltöltés megkezdése előtt. A hálózati sebesség korlátozásai mellett ez a pufferelési viselkedés is okot ad arra, hogy kisebb értéket MaximumTransferSizevegyenek figyelembe, még akkor is, ha egymás után töltik fel. Az érték MaximumTransferSize csökkentése csökkenti az egyes kéréseken pufferelt adatok maximális mennyiségét, és a sikertelen kérések minden újrapróbálkozását. Ha egy bizonyos méretű adatátvitel során gyakori időtúllépés lép fel, a MaximumTransferSize pufferelési idő csökkentése jobb teljesítményt eredményezhet.

A pufferelés másik forgatókönyve az, amikor párhuzamos REST-hívásokkal tölt fel adatokat a hálózati átviteli sebesség maximalizálása érdekében. Az ügyfélkódtáraknak olyan forrásokra van szükségük, amelyekből párhuzamosan olvashatnak, és mivel a streamek szekvenciálisak, a Storage-ügyfélkódtárak a feltöltés megkezdése előtt pufferelik az egyes REST-hívások adatait. Ez a pufferelési viselkedés akkor is előfordul, ha a megadott stream kereshető.

Az aszinkron feltöltési hívás során történő pufferelés elkerülése érdekében meg kell adnia egy kereshető streamet, és 1 értékre kell állítania MaximumConcurrency . Bár ennek a stratégiának a legtöbb helyzetben működnie kell, a pufferelés akkor is lehetséges, ha a kód más, pufferelést igénylő ügyfélkódtár-funkciókat használ.

InitialTransferSize a feltöltéskor

Ha egy kereshető streamet ad meg a feltöltéshez, a rendszer ellenőrzi a stream hosszát a következő értéken InitialTransferSize: . Ha a stream hossza kisebb ennél az értéknél, a rendszer a teljes adatfolyamot egyetlen REST-hívásként tölti fel, a többi StorageTransferOptions értéktől függetlenül. Ellenkező esetben a feltöltés több részből áll, a korábban leírtak szerint. InitialTransferSize nincs hatása a nem kereshető streamre, és figyelmen kívül marad.

A letöltések teljesítményével kapcsolatos szempontok

A letöltés során a Storage-ügyfélkódtárak egy adott letöltési kérelmet több alletöltésre osztottak fel a StorageTransferOptions példányban meghatározott értékek alapján. Minden részletöltésnek saját hívása van a REST-műveletre. Az átviteli lehetőségektől függően az ügyfélkódtárak párhuzamosan kezelik ezeket a REST-műveleteket a teljes letöltés befejezéséhez.

Pufferelés letöltések során

A több HTTP-válasz egyidejű fogadása a törzs tartalmával hatással van a memóriahasználatra. A Storage-ügyfélkódtárak azonban nem adnak hozzá explicit módon pufferlépést a letöltött tartalmakhoz. A bejövő válaszok feldolgozása sorrendben történik. Az ügyfélkódtárak 16 kilobájtos puffert konfigurálnak a streamek HTTP-válaszfolyamból egy hívó által biztosított célstreambe vagy fájlelérési útvonalra való másolásához.

Kezdeti átviteli méret letöltéskor

A letöltés során a Storage-ügyfélkódtárak egy letöltési tartományra vonatkozó kérést InitialTransferSize hajtanak létre, mielőtt bármi mást megtennének. A kezdeti letöltési kérelem során az ügyfélkódtárak ismerik az erőforrás teljes méretét. Ha a kezdeti kérés sikeresen letöltötte az összes tartalmat, a művelet befejeződött. Ellenkező esetben a kliensek a teljes letöltés befejezéséig továbbra is tartománykéréseket hajtanak végre MaximumTransferSize.

Következő lépések

  • Last updated on