Prestandajustering för uppladdningar och nedladdningar med Python

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. Standardläget är inställt på 4 MiB.
• max_concurrency: Det maximala antalet undertransfers som kan användas parallellt.

maximal_enkel_putstorlek

Argumentet max_single_put_size är den maximala blobstorleken i byte för en enda begärandeuppladdning. Om blobstorleken är mindre än eller lika med max_single_put_size 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_sizeinte 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_storlek

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 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. Vid instansiering av klienten sätter vi max_single_put_size 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 å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.

Buffring under uppladdningar

Storage REST-lagret stöder inte att fortsätta en REST-uppladdningsoperation där du slutade, enskilda överföringar är antingen slutförda eller förlorade. 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 max_block_size byte data per samtidig underöverföringsbegä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 som standard 4*1024*1024 + 1.
• 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. Standardläget är inställt på 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 max_single_get_sizeöverskrider hämtas resten av blobdata i segment. Standardvärdet är 32 MiB.
• connection_data_block_size: Anger storleken på datablock som lästs från nätverksströmmen. Det förinställda värdet är 4 KiB.

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
        connection_data_block_size=1024*4, # 4 KiB
    )

    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 subnedladdning har ett eget dedikerat anrop till REST-operationen. 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.

anslutning_data_blockstorlek för nedladdningar

Under en nedladdning kan inställningen avsevärt påverka nedladdningsprestanda connection_data_block_size . Dess inverkan är mycket beroende av din specifika miljö och maskinvarukonfiguration. Prova att börja med ett värde som 64KiB och justera det gradvis för att hitta den optimala balansen vid övervakning av prestanda och resursanvändning.

Nästa steg

• Den här artikeln är en del av utvecklarguiden för Blob Storage för Python. Se den fullständiga listan över utvecklarguideartiklar i Skapa din app.
• Mer information om faktorer som kan påverka prestanda för Azure Storage-åtgärder finns i Svarstid i Blob Storage.
• En lista över designöverväganden för att optimera prestanda för appar med bloblagring finns i Checklista för prestanda och skalbarhet för Blob Storage.