Dela via

Prestandajustering för uppladdningar och nedladdningar med Python

  • Artikel

När ett program överför data med hjälp av Azure Storage-klientbiblioteket för Python finns det flera faktorer som kan påverka hastighet, minnesanvändning och till och med lyckade eller misslyckade begäranden. För att maximera prestanda och tillförlitlighet för dataöverföringar är det viktigt att vara proaktiv när det gäller att konfigurera överföringsalternativ för klientbibliotek baserat på den miljö som appen körs i.

Den här artikeln går igenom flera överväganden för att justera alternativ för dataöverföring. När klientbiblioteket är korrekt justerat kan det effektivt distribuera data över flera begäranden, vilket kan leda till förbättrad drifthastighet, minnesanvändning och nätverksstabilitet.

Prestandajustering för uppladdningar

Korrekt justering av dataöverföringsalternativ är nyckeln till tillförlitlig prestanda för uppladdningar. Lagringsöverföringar partitioneras i flera undertransfers baserat på värdena för dessa argument. Den maximala överföringsstorleken som stöds varierar beroende på åtgärd och tjänstversion, så se till att kontrollera dokumentationen för att fastställa gränserna. Mer information om överföringsstorleksgränser för Blob Storage finns i Skalningsmål för Blob Storage.

Ange överföringsalternativ för uppladdningar

Följande argument kan justeras baserat på appens behov:

  • max_single_put_size: Den maximala storleken för en blob som ska laddas upp med en enda begäran. Standardvärdet är 64 MiB.
  • max_block_size: Den maximala längden på en överföring i byte när du laddar upp en blockblob i segment. Standardvärdet är 4 MiB.
  • max_concurrency: Det maximala antalet undertransfers som kan användas parallellt.

Kommentar

Klientbiblioteken använder standardvärden för varje alternativ för dataöverföring, om de inte anges. Dessa standardvärden fungerar vanligtvis i en datacentermiljö, men är troligen inte lämpliga för hemkonsumentmiljöer. Dåligt anpassade alternativ för dataöverföring kan resultera i överdrivet långa åtgärder och till och med tidsgränser för begäranden. Det är bäst att vara proaktiv när det gäller att testa dessa värden och justera dem baserat på behoven i ditt program och din miljö.

max_single_put_size

Argumentet max_single_put_size är den maximala blobstorleken i byte för en enda begärandeuppladdning. Om blobstorleken är mindre än eller lika max_single_put_sizemed laddas blobben upp med en enda Put Blob-begäran . Om blobstorleken är större än max_single_put_size, eller om blobstorleken är okänd, laddas blobben upp i segment med hjälp av en serie Put Block-anrop följt av Placera blockeringslista.

Det är viktigt att observera att det värde du anger för max_block_size inte begränsar det värde som du definierar för max_single_put_size. Argumentet max_single_put_size definierar en separat storleksbegränsning för en begäran om att utföra hela åtgärden samtidigt, utan undertransfers. Det är ofta så att du vill max_single_put_size vara minst lika stor som värdet du definierar för max_block_size, om inte större. Beroende på storleken på dataöverföringen kan den här metoden vara mer högpresterande eftersom överföringen slutförs med en enda begäran och undviker omkostnaderna för flera begäranden.

Om du är osäker på vilket värde som är bäst för din situation är ett säkert alternativ att ange max_single_put_size samma värde som används för max_block_size.

max_block_size

Argumentet max_block_size är den maximala längden på en överföring i byte vid uppladdning av en blockblob i segment. Som tidigare nämnts begränsar inte det här värdet , som kan vara större än max_block_size. max_single_put_size

För att hålla data i rörelse effektivt kanske klientbiblioteken inte alltid når max_block_size värdet för varje överföring. Beroende på åtgärden kan det maximala värdet för överföringsstorleken variera. Mer information om gränserna för överföringsstorlek för Blob Storage finns i diagrammet i Skala mål för Blob Storage.

Kodexempel

Följande kodexempel visar hur du anger alternativ för dataöverföring när du skapar ett BlobClient objekt och hur du laddar upp data med det klientobjektet. De värden som anges i det här exemplet är inte avsedda att vara en rekommendation. Om du vill justera dessa värden korrekt måste du ta hänsyn till appens specifika behov.

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)

I det här exemplet anger vi antalet parallella överföringsarbetare till 2 med argumentet max_concurrency i metodanropet. Den här konfigurationen öppnar upp till två anslutningar samtidigt, vilket gör att uppladdningen kan ske parallellt. Under klient-instansieringen anger max_single_put_size vi argumentet till 8 MiB. Om blobstorleken är mindre än 8 MiB krävs bara en enda begäran för att slutföra uppladdningen. Om blobstorleken är större än 8 MiB laddas bloben upp i segment med en maximal segmentstorlek på 4 MiB, enligt max_block_size argumentet.

Prestandaöverväganden för uppladdningar

Under en uppladdning delade Storage-klientbiblioteken upp en viss uppladdningsström i flera underuppdateringar baserat på de konfigurationsalternativ som definierades under klientkonstruktionen. Varje underuppladdning har ett eget dedikerat anrop till REST-åtgärden. För ett BlobClient objekt är den här åtgärden Placera block. Storage-klientbiblioteket hanterar dessa REST-åtgärder parallellt (beroende på överföringsalternativ) för att slutföra den fullständiga uppladdningen.

Du kan lära dig hur klientbiblioteket hanterar buffring i följande avsnitt.

Kommentar

Blockblobar har ett maximalt blockantal på 50 000 block. Den maximala storleken på blockbloben är då 50 000 gånger max_block_size.

Buffring under uppladdningar

Storage REST-lagret har inte stöd för att hämta en REST-uppladdningsåtgärd där du slutade. enskilda överföringar antingen slutförs eller förloras. För att säkerställa återhämtning för dataströmuppladdningar buffrar Storage-klientbiblioteken data för varje enskilt REST-anrop innan uppladdningen startas. Förutom begränsningar i nätverkshastigheten är det här buffringsbeteendet en anledning att överväga ett mindre värde för max_block_size, även när du laddar upp i sekvens. Om du minskar värdet för max_block_size minskar den maximala mängden data som buffrats för varje begäran och varje nytt försök av en misslyckad begäran. Om du har frekventa timeouter under dataöverföringar av en viss storlek minskar en minskning av max_block_size värdet för buffringstiden och kan resultera i bättre prestanda.

SDK buffrar som standard data max_block_size om byte per samtidig underbelastningsbegäran, men minnesanvändningen kan begränsas till 4 MiB per begäran om följande villkor uppfylls:

  • Argumentet max_block_size måste vara större än min_large_block_upload_threshold. Argumentet min_large_block_upload_threshold kan definieras under klient-instansieringen och är den minsta segmentstorleken i byte som krävs för att använda den minneseffektiva algoritmen. Argumentet min_large_block_upload_threshold är 4*1024*1024 + 1som standard .
  • Den angivna strömmen måste vara sökbar. En sökbar ström är en ström som stöder frågor och ändringar av den aktuella positionen i en dataström.
  • Bloben måste vara en blockblob.

Även om den här strategin gäller för de flesta situationer är det fortfarande möjligt att mer buffring sker om koden använder andra klientbiblioteksfunktioner som kräver buffring.

Prestandajustering för nedladdningar

Korrekt justering av dataöverföringsalternativ är nyckeln till tillförlitlig prestanda för nedladdningar. Lagringsöverföringar partitioneras i flera undertransfers baserat på värdena för dessa argument.

Ange överföringsalternativ för nedladdningar

Följande argument kan justeras baserat på appens behov:

  • max_chunk_get_size: Den maximala segmentstorleken som används för att ladda ned en blob. Standardvärdet är 4 MiB.
  • max_concurrency: Det maximala antalet undertransfers som kan användas parallellt.
  • max_single_get_size: Den maximala storleken för en blob som ska laddas ned i ett enda anrop. Om den totala blobstorleken överskrider laddas max_single_get_sizeresten av blobdata ned i segment. Standardvärdet är 32 MiB.

Kodexempel

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())

Prestandaöverväganden för nedladdningar

Under en nedladdning delar Lagringsklientbiblioteken upp en viss nedladdningsbegäran i flera undernedladdningar baserat på de konfigurationsalternativ som definierades under klientkonstruktionen. Varje underdelast har ett eget dedikerat anrop till REST-åtgärden. Beroende på överföringsalternativ hanterar klientbiblioteken dessa REST-åtgärder parallellt för att slutföra den fullständiga nedladdningen.

max_single_get_size för nedladdningar

Under en nedladdning gör Storage-klientbiblioteken en begäran om nedladdningsintervall med hjälp av max_single_get_size innan du gör något annat. Under den första nedladdningsbegäran känner klientbiblioteken till resursens totala storlek. Om den första begäran har laddat ned allt innehåll är åtgärden slutförd. Annars fortsätter klientbiblioteken att göra intervallbegäranden fram tills max_chunk_get_size den fullständiga nedladdningen är klar.

Nästa steg