Share via

Prestaties afstemmen voor uploads en downloads met Python

  • Artikel

Wanneer een toepassing gegevens overdraagt met behulp van de Azure Storage-clientbibliotheek voor Python, zijn er verschillende factoren die van invloed kunnen zijn op snelheid, geheugengebruik en zelfs het slagen of mislukken van de aanvraag. Om de prestaties en betrouwbaarheid voor gegevensoverdracht te maximaliseren, is het belangrijk om proactief te zijn bij het configureren van opties voor clientbibliotheekoverdracht op basis van de omgeving waarin uw app wordt uitgevoerd.

In dit artikel worden verschillende overwegingen beschreven voor het afstemmen van opties voor gegevensoverdracht. Wanneer de clientbibliotheek correct is afgestemd, kan de clientbibliotheek gegevens efficiënt distribueren over meerdere aanvragen, wat kan leiden tot een verbeterde werkingssnelheid, geheugengebruik en netwerkstabiliteit.

Prestaties afstemmen voor uploads

De opties voor het correct afstemmen van gegevensoverdracht zijn essentieel voor betrouwbare prestaties voor uploads. Opslagoverdrachten worden gepartitioneerd in verschillende subtransfers op basis van de waarden van deze argumenten. De maximale ondersteunde overdrachtsgrootte verschilt per bewerkings- en serviceversie. Controleer daarom de documentatie om de limieten te bepalen. Zie Schaaldoelen voor Blob-opslag voor meer informatie over de limieten voor de overdrachtsgrootte voor Blob Storage.

Overdrachtsopties instellen voor uploads

De volgende argumenten kunnen worden afgestemd op basis van de behoeften van uw app:

  • max_single_put_size: De maximale grootte voor een blob die met één aanvraag moet worden geüpload. De standaardwaarde is 64 MiB.
  • max_block_size: De maximale lengte van een overdracht in bytes bij het uploaden van een blok-blob in segmenten. De standaardwaarde is 4 MiB.
  • max_concurrency: Het maximum aantal subtransfers dat parallel kan worden gebruikt.

Notitie

De clientbibliotheken gebruiken standaardwaarden voor elke optie voor gegevensoverdracht, indien niet opgegeven. Deze standaardwaarden werken doorgaans in een datacentrumomgeving, maar zijn waarschijnlijk niet geschikt voor thuisconsumentenomgevingen. Slecht afgestemde opties voor gegevensoverdracht kunnen leiden tot overmatig lange bewerkingen en zelfs time-outs voor aanvragen. Het is het beste om proactief te zijn bij het testen van deze waarden en het afstemmen ervan op basis van de behoeften van uw toepassing en omgeving.

max_single_put_size

Het max_single_put_size argument is de maximale blobgrootte in bytes voor het uploaden van één aanvraag. Als de blobgrootte kleiner is dan of gelijk is aan max_single_put_size, wordt de blob geüpload met één Put Blob-aanvraag . Als de blob groter is dan max_single_put_sizeof als de blobgrootte onbekend is, wordt de blob geüpload in segmenten met behulp van een reeks Put Block-aanroepen gevolgd door Put Block List.

Het is belangrijk te weten dat de waarde die u opgeeft max_block_size , niet de waarde beperkt die u definieert.max_single_put_size Het max_single_put_size argument definieert een afzonderlijke groottebeperking voor een aanvraag om de hele bewerking tegelijk uit te voeren, zonder suboverdrachten. Het is vaak het geval dat u minstens zo groot wilt max_single_put_size zijn als de waarde die u definieertmax_block_size, als deze niet groter is. Afhankelijk van de grootte van de gegevensoverdracht kan deze methode beter presteren, omdat de overdracht wordt voltooid met één aanvraag en de overhead van meerdere aanvragen wordt vermeden.

Als u niet zeker weet welke waarde het beste is voor uw situatie, is een veilige optie om in te stellen max_single_put_size op dezelfde waarde die wordt gebruikt voor max_block_size.

max_block_size

Het max_block_size argument is de maximale lengte van een overdracht in bytes bij het uploaden van een blok-blob in segmenten. Zoals eerder vermeld, wordt deze waarde niet beperkt max_single_put_size, wat groter kan zijn dan max_block_size.

Om gegevens efficiënt te laten bewegen, bereiken de clientbibliotheken mogelijk niet altijd de max_block_size waarde voor elke overdracht. Afhankelijk van de bewerking kan de maximale ondersteunde waarde voor de overdrachtsgrootte variëren. Zie de grafiek in Schaaldoelen voor Blob Storage voor meer informatie over de overdrachtsgroottelimieten voor Blob Storage.

Voorbeeld van code

In het volgende codevoorbeeld ziet u hoe u opties voor gegevensoverdracht opgeeft bij het maken van een BlobClient object en hoe u gegevens uploadt met behulp van dat clientobject. De waarden in dit voorbeeld zijn niet bedoeld als aanbeveling. Als u deze waarden goed wilt afstemmen, moet u rekening houden met de specifieke behoeften van uw app.

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)

In dit voorbeeld stellen we het aantal parallelle overdrachtswerkers in op 2, met behulp van het max_concurrency argument voor de methode-aanroep. Met deze configuratie worden twee verbindingen tegelijk geopend, waardoor het uploaden parallel kan plaatsvinden. Tijdens het instanteren van de client stellen we het max_single_put_size argument in op 8 MiB. Als de blob kleiner is dan 8 MiB, is slechts één aanvraag nodig om de uploadbewerking te voltooien. Als de blob groter is dan 8 MiB, wordt de blob geüpload in segmenten met een maximale segmentgrootte van 4 MiB, zoals ingesteld door het max_block_size argument.

Prestatieoverwegingen voor uploads

Tijdens het uploaden splitsen de Storage-clientbibliotheken een bepaalde uploadstroom in meerdere subuploads op basis van de configuratieopties die tijdens de clientconstructie zijn gedefinieerd. Elke subupload heeft een eigen toegewezen aanroep naar de REST-bewerking. Voor een BlobClient object is deze bewerking Put Block. De Storage-clientbibliotheek beheert deze REST-bewerkingen parallel (afhankelijk van overdrachtsopties) om het volledige uploaden te voltooien.

In de volgende secties leert u hoe de clientbibliotheek buffering verwerkt.

Notitie

Blok-blobs hebben een maximumaantal blokken van 50.000 blokken. De maximale grootte van uw blok-blob is dan 50.000 keer max_block_size.

Bufferen tijdens uploads

De Opslag REST-laag biedt geen ondersteuning voor het ophalen van een REST-uploadbewerking waar u was gebleven; afzonderlijke overdrachten worden voltooid of verloren gegaan. Om tolerantie voor streamuploads te garanderen, bufferen de Storage-clientbibliotheken gegevens voor elke afzonderlijke REST-aanroep voordat de upload wordt gestart. Naast netwerksnelheidsbeperkingen is dit buffergedrag een reden om rekening te houden met een kleinere waarde voor max_block_size, zelfs bij het uploaden in volgorde. Als u de waarde verlaagt, max_block_size wordt de maximale hoeveelheid gegevens die wordt gebufferd voor elke aanvraag en elke nieuwe poging van een mislukte aanvraag verkleint. Als u regelmatig time-outs ondervindt tijdens gegevensoverdrachten van een bepaalde grootte, vermindert u de waarde van het verminderen van max_block_size de buffertijd en kan dit leiden tot betere prestaties.

De SDK buffert standaard gegevens van max_block_size bytes per gelijktijdige subuploadaanvraag, maar geheugengebruik kan worden beperkt tot 4 MiB per aanvraag als aan de volgende voorwaarden wordt voldaan:

  • Het max_block_size argument moet groter zijn dan min_large_block_upload_threshold. Het min_large_block_upload_threshold argument kan worden gedefinieerd tijdens het instantiëring van de client en is de minimale segmentgrootte in bytes die nodig zijn om het geheugenefficiënte algoritme te gebruiken. Het min_large_block_upload_threshold argument wordt standaard ingesteld op 4*1024*1024 + 1.
  • De opgegeven stream moet kunnen worden gezocht. Een doorzoekbare stream is een stroom die ondersteuning biedt voor het uitvoeren van query's en het wijzigen van de huidige positie binnen een stroom.
  • De blob moet een blok-blob zijn.

Hoewel deze strategie van toepassing is op de meeste situaties, is het nog steeds mogelijk dat er meer buffering plaatsvindt als uw code gebruikmaakt van andere clientbibliotheekfuncties waarvoor buffering is vereist.

Prestaties afstemmen voor downloads

De opties voor het correct afstemmen van gegevensoverdracht zijn essentieel voor betrouwbare prestaties voor downloads. Opslagoverdrachten worden gepartitioneerd in verschillende subtransfers op basis van de waarden van deze argumenten.

Overdrachtsopties instellen voor downloads

De volgende argumenten kunnen worden afgestemd op basis van de behoeften van uw app:

  • max_chunk_get_size: De maximale segmentgrootte die wordt gebruikt voor het downloaden van een blob. De standaardwaarde is 4 MiB.
  • max_concurrency: Het maximum aantal subtransfers dat parallel kan worden gebruikt.
  • max_single_get_size: De maximale grootte voor een blob die in één aanroep moet worden gedownload. Als de totale blobgrootte groter is max_single_get_size, wordt de rest van de blobgegevens gedownload in segmenten. De standaardwaarde is 32 MiB.

Voorbeeld van code

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

Prestatieoverwegingen voor downloads

Tijdens een download splitsen de Storage-clientbibliotheken een bepaalde downloadaanvraag in meerdere subdownloads op basis van de configuratieopties die tijdens de clientconstructie zijn gedefinieerd. Elke subdownload heeft een eigen toegewezen aanroep naar de REST-bewerking. Afhankelijk van overdrachtsopties beheren de clientbibliotheken deze REST-bewerkingen parallel om de volledige download te voltooien.

max_single_get_size voor downloads

Tijdens een download maken de Storage-clientbibliotheken één aanvraag voor het downloadbereik die wordt gebruikt max_single_get_size voordat ze iets anders doen. Tijdens deze eerste downloadaanvraag kennen de clientbibliotheken de totale grootte van de resource. Als de initiële aanvraag alle inhoud heeft gedownload, is de bewerking voltooid. Anders blijven de clientbibliotheken bereikaanvragen totdat max_chunk_get_size de volledige download is voltooid.

Volgende stappen