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

  • Cikk

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árátadások több altranszferre vannak particionálva a szerkezet 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 művelet túl hosszú műveleteket eredményezhet, és akár időtúllépéseket is igényelhet. 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.

InitialTransferSize

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 legalább akkora értéket szeretne InitialTransferSize megadni, mint a megadott MaximumTransferSizeérték, ha nem nagyobb. 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

Objektum használata BlobClient esetén a put blob helyett a Put Blob használatával kell feltölteni a InitialTransferSize blobot.

Maximális konkurencia

A MaximumKonkurencia a párhuzamos átvitelben használható feldolgozó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. A .NET-ben a kapcsolatkészlet korlátairól további információt .NET-keretrendszer kapcsolatkészlet korlátairól és az új Azure SDK for .NET-ről talál.

MaximumTransferSize

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ódtárak nem mindig érik el az MaximumTransferSize összes átvitel értékét. A művelettől függően az átviteli méret maximális támogatott értéke eltérő lehet. Például a 2019-12-12-es vagy újabb szolgáltatásverzióval meghívó blokkblobok 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 túlterheléseket tartalmaz a Upload metódusokhoz, UploadAsync amelyek egy StorageTransferOptions-példányt fogadnak el a BlobUploadOptions paraméter részeként. Hasonló túlterhelések is léteznek a DownloadTo BlobDownloadToOptions paraméterrel rendelkező metódusokhoz és DownloadToAsync metódusokhoz.

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 feltöltések teljesítményével kapcsolatos szempontok

A feltöltés során a Storage-ügyfélkódtárak egy adott feltöltési adatfolyamot több részadatra osztanak fel a StorageTransferOptions példányban meghatározott értékek alapján. Minden alterhelés saját dedikált hívással rendelkezik a REST-művelethez. 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éseket tapasztal, a MaximumTransferSize pufferelési idő csökkentésével 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 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 hagyja.

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 alletöltés saját dedikált hívással rendelkezik a REST-művelethez. 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.

InitialTransferSize 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 az ügyfélkódtárak a teljes letöltés befejezéséig továbbra is tartománykéréseket hajtanak MaximumTransferSize végre.

Következő lépések