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


Feltöltések és letöltések teljesítményhangolása a Pythonnal

Amikor egy alkalmazás adatokat továbbít a Pythonhoz készült Azure Storage-ügyfélkódtár használatával, 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. 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.

Feltöltések teljesítményhangolása

Az adatátviteli beállítások megfelelő finomhangolása kulcsfontosságú a feltöltések megbízható teljesítményéhez. A tárolóátvitelek több altranszferre vannak particionálva ezen argumentumok értékei 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.

A feltöltések átviteli beállításainak megadása

Az alábbi argumentumok hangolhatók az alkalmazás igényei szerint:

  • max_single_put_size: Egy blob egyetlen kéréssel való feltöltésének maximális mérete. Alapértelmezés szerint 64 miB.
  • max_block_size: Az átvitel maximális hossza bájtban, ha blokkblobot tölt fel adattömbökbe. Alapértelmezés szerint 4 MiB.
  • max_concurrency: A párhuzamosan használható altranszferek maximális száma.

Megjegyzés:

Ha nincs megadva, az ügyfélkódtárak minden adatátviteli lehetőséghez alapértelmezett értékeket használnak. 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 adatátviteli lehetőségek túlzottan hosszú műveleteket és akár időtúllépéseket is eredményezhetnek. A legjobb, ha proaktívan teszteli ezeket az értékeket, és az alkalmazás és a környezet igényeinek megfelelően finomhangolja őket.

max_single_put_size

Az max_single_put_size argumentum egy kérelemfeltöltés maximális blobmérete bájtban. Ha a blob mérete kisebb vagy egyenlő max_single_put_size, a blob egyetlen Put Blob-kéréssel lesz feltöltve. Ha a blob mérete nagyobb, mint max_single_put_size, vagy ha a blob mérete ismeretlen, a blob adattömbökbe lesz feltöltve a Put Block hívások sorozatával, majd a Blokkok listával.

Fontos megjegyezni, hogy a megadott max_block_sizeérték nem korlátozza a megadott max_single_put_sizeértéket. Az max_single_put_size argumentum külön méretkorlátozást határoz meg a teljes művelet egyidejű végrehajtására irányuló kéréshez, altranszferek nélkül. Gyakran előfordul, hogy legalább akkora értéket szeretne max_single_put_sizemegadni, mint a megadott max_block_sizeé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 max_single_put_size , amelyet a rendszer használ max_block_size.

max_block_size

Az max_block_size argumentum az átvitel maximális hossza bájtban, amikor blokkblobot tölt fel adattömbökbe. Ahogy korábban említettük, ez az érték nem korlátozza a korlátot max_single_put_size, amely nagyobb lehet, mint max_block_size.

Az adatok hatékony mozgásának fenntartása érdekében előfordulhat, hogy az ügyfélkódtárak nem mindig érik el az max_block_size ö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. 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 alábbi példakód bemutatja, hogyan adhatja meg az adatátviteli beállításokat egy BlobClient objektum létrehozásakor, és hogyan tölthet fel adatokat az ügyfélobjektum használatával. 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.

def upload_blob_transfer_options(self, account_url: str, container_name: str, blob_name: str):
    # Create a BlobClient object with data transfer options for upload
    blob_client = BlobClient(
        account_url=account_url, 
        container_name=container_name, 
        blob_name=blob_name,
        credential=DefaultAzureCredential(),
        max_block_size=1024*1024*4, # 4 MiB
        max_single_put_size=1024*1024*8 # 8 MiB
    )
    
    with open(file=os.path.join(r'file_path', blob_name), mode="rb") as data:
        blob_client = blob_client.upload_blob(data=data, overwrite=True, max_concurrency=2)

Ebben a példában a párhuzamos átviteli feldolgozók számát 2 értékre állítjuk a max_concurrency metódushívás argumentumával. Ez a konfiguráció egyszerre legfeljebb két kapcsolatot nyit meg, így a feltöltés párhuzamosan történik. Az ügyfél példányosítása során az max_single_put_size argumentumot 8 MiB értékre állítjuk. Ha a blob mérete kisebb, mint 8 MiB, csak egyetlen kérelem szükséges a feltöltési művelet végrehajtásához. Ha a blob mérete nagyobb, mint 8 MiB, akkor a blob legfeljebb 4 MiB méretű adattömbökbe tölthető fel az max_block_size argumentum által megadott módon.

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 az ügyfélépítés során meghatározott konfigurációs beállítások alapján. Minden alterhelés saját dedikált hívással rendelkezik a REST-művelethez. Objektum BlobClient esetén ez a művelet a Blokk elhelyezé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.

A következő szakaszokban megtudhatja, hogyan kezeli az ügyfélkódtár a pufferelést.

Megjegyzés:

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

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 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 max_block_sizevegyenek figyelembe, még akkor is, ha egymás után töltik fel. Az érték max_block_size 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 max_block_size pufferelési idő csökkentésével jobb teljesítményt eredményezhet.

Az SDK alapértelmezés szerint bájtok adatait max_block_size puffereli egyidejű részterhelési kérésenként, de a memóriahasználat kérésenként legfeljebb 4 MiB lehet, ha a következő feltételek teljesülnek:

  • Az max_block_size argumentumnak nagyobbnak kell lennie, mint min_large_block_upload_threshold. Az min_large_block_upload_threshold argumentum definiálható az ügyfél példányosítása során, és a memóriahatékony algoritmus használatához szükséges minimális adattömbméret bájtokban. Az min_large_block_upload_threshold argumentum alapértelmezés szerint a következő.4*1024*1024 + 1
  • A megadott streamnek kereshetőnek kell lennie. 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 blobnak blokkblobnak kell lennie.

Bár ez a stratégia a legtöbb helyzetben érvényes, akkor is lehetséges további pufferelés, ha a kód más, pufferelést igénylő ügyfélkódtár-funkciókat használ.

Letöltések teljesítményhangolása

Az adatátviteli lehetőségek megfelelő finomhangolása kulcsfontosságú a letöltések megbízható teljesítményéhez. A tárolóátvitelek több altranszferre vannak particionálva ezen argumentumok értékei alapján.

Letöltések átviteli beállításainak megadása

Az alábbi argumentumok hangolhatók az alkalmazás igényei szerint:

  • max_chunk_get_size: A blob letöltéséhez használt maximális adattömbméret. Alapértelmezés szerint 4 MiB.
  • max_concurrency: A párhuzamosan használható altranszferek maximális száma.
  • max_single_get_size: Egy blob egyetlen hívásban való letöltésének maximális mérete. Ha a blob teljes mérete meghaladja max_single_get_sizea teljes méretet, a blobadatok fennmaradó része adattömbökben lesz letöltve. Alapértelmezés szerint 32 miB.

Mintakód

def download_blob_transfer_options(self, account_url: str, container_name: str, blob_name: str):
    # Create a BlobClient object with data transfer options for download
    blob_client = BlobClient(
        account_url=account_url, 
        container_name=container_name, 
        blob_name=blob_name,
        credential=DefaultAzureCredential(),
        max_single_get_size=1024*1024*32, # 32 MiB
        max_chunk_get_size=1024*1024*4 # 4 MiB
    )

    with open(file=os.path.join(r'file_path', 'file_name'), mode="wb") as sample_blob:
        download_stream = blob_client.download_blob(max_concurrency=2)
        sample_blob.write(download_stream.readall())

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 az ügyfélépítés során meghatározott konfigurációs beállítások 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.

max_single_get_size letöltésekhez

A letöltés során a Storage-ügyfélkódtárak egy letöltési tartományra vonatkozó kérést max_single_get_size 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 max_chunk_get_size végre.

Következő lépések