Delen via

Prestaties afstemmen voor uploads en downloads met .NET

  • Artikel

Wanneer een toepassing gegevens overdraagt met behulp van de Azure Storage-clientbibliotheek voor .NET, 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. De richtlijnen zijn van toepassing op api's die als parameter worden geaccepteerd StorageTransferOptions . 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 met StorageTransferOptions

Het correct afstemmen van de waarden in StorageTransferOptions is essentieel voor betrouwbare prestaties voor gegevensoverdrachtbewerkingen. Opslagoverdrachten worden gepartitioneerd in verschillende subtransfers op basis van de eigenschapswaarden die zijn gedefinieerd in een exemplaar van deze struct. 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.

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

Notitie

Hoewel de StorageTransferOptions struct null-waarden bevat, gebruiken de clientbibliotheken standaardwaarden voor elke afzonderlijke waarde, indien niet opgegeven. Deze standaardwaarden werken doorgaans in een datacentrumomgeving, maar zijn waarschijnlijk niet geschikt voor thuisconsumentenomgevingen. Slecht afgestemd StorageTransferOptions kan leiden tot overmatig lange bewerkingen en zelfs time-outs voor aanvragen. Het is raadzaam om proactief te zijn bij het testen van de waarden in StorageTransferOptionsen het afstemmen ervan op basis van de behoeften van uw toepassing en omgeving.

InitialTransfersize

InitialTransferSize is de grootte van de eerste bereikaanvraag in bytes. Een HTTP-bereikaanvraag is een gedeeltelijke aanvraag, met de grootte die in dit geval is gedefinieerd InitialTransferSize . Blobs die kleiner zijn dan deze grootte, worden in één aanvraag overgedragen. Blobs die groter zijn dan deze grootte, worden nog steeds overgebracht in segmenten van grootte MaximumTransferSize.

Het is belangrijk te weten dat de waarde die u opgeeft MaximumTransferSize , niet de waarde beperkt die u definieert.InitialTransferSize InitialTransferSize definieert een afzonderlijke groottebeperking voor een eerste aanvraag om de hele bewerking tegelijk uit te voeren, zonder suboverdrachten. Het is vaak het geval dat u minstens zo groot wilt InitialTransferSize zijn als de waarde die u definieertMaximumTransferSize, 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 InitialTransferSize op dezelfde waarde die wordt gebruikt voor MaximumTransferSize.

Notitie

Wanneer u een BlobClient object gebruikt, wordt het uploaden van een blob kleiner dan de InitialTransferSize blob uitgevoerd met behulp van Put Blob, in plaats van Put Block.

MaximumConcurrency

MaximumConcurrency is het maximum aantal werknemers dat kan worden gebruikt in een parallelle overdracht. Op dit moment kunnen alleen asynchrone bewerkingen overdrachten parallelliseren. Synchrone bewerkingen negeren deze waarde en werken in volgorde.

De effectiviteit van deze waarde is onderhevig aan verbindingsgroeplimieten in .NET, waardoor de prestaties in bepaalde scenario's standaard kunnen worden beperkt. Zie limieten voor .NET Framework-verbindingsgroepen en de nieuwe Azure SDK voor .NET voor meer informatie over limieten voor verbindingsgroepen in .NET.

MaximumTransferSize

MaximumTransferSize is de maximale lengte van een overdracht in bytes. Zoals eerder vermeld, wordt deze waarde niet beperkt InitialTransferSize, wat groter kan zijn dan MaximumTransferSize.

Om gegevens efficiënt te laten bewegen, bereiken de clientbibliotheken mogelijk niet altijd de MaximumTransferSize waarde voor elke overdracht. Afhankelijk van de bewerking kan de maximale ondersteunde waarde voor de overdrachtsgrootte variëren. Blok-blobs die bijvoorbeeld de Put Block-bewerking aanroepen met een serviceversie van 2019-12-12 of hoger, hebben een maximale blokgrootte van 4000 MiB. Zie de grafiek in Schaaldoelen voor Blob Storage voor meer informatie over de overdrachtsgroottelimieten voor Blob Storage.

Voorbeeld van code

De clientbibliotheek bevat overbelastingen voor de Upload en UploadAsync methoden, die een StorageTransferOptions-exemplaar accepteren als onderdeel van een blobUploadOptions-parameter . Vergelijkbare overbelastingen bestaan ook voor de DownloadTo en DownloadToAsync methoden met behulp van een blobDownloadToOptions-parameter .

In het volgende codevoorbeeld ziet u hoe u waarden voor een StorageTransferOptions exemplaar definieert en deze configuratieopties als parameter doorgeeft aan UploadAsync. 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.

// 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);

In dit voorbeeld stellen we het aantal parallelle overdrachtsmedewerkers in op 2, met behulp van de MaximumConcurrency eigenschap. Met deze configuratie worden twee verbindingen tegelijk geopend, waardoor het uploaden parallel kan plaatsvinden. De eerste HTTP-bereikaanvraag probeert maximaal 8 MiB aan gegevens te uploaden, zoals gedefinieerd door de InitialTransferSize eigenschap. Houd er rekening mee dat InitialTransferSize alleen van toepassing is op uploads wanneer u een zoekbare stream gebruikt. Als de blob kleiner is dan 8 MiB, is slechts één aanvraag nodig om de bewerking te voltooien. Als de blob groter is dan 8 MiB, hebben alle volgende overdrachtsaanvragen een maximale grootte van 4 MiB, die we met de MaximumTransferSize eigenschap hebben ingesteld.

Prestatieoverwegingen voor uploads

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

Afhankelijk van of de uploadstream kan worden gezocht of niet kan worden gezocht, verwerkt de clientbibliotheek buffering en InitialTransferSize anders, zoals beschreven in de volgende secties. 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. Zie de Stream-klassereferentie voor meer informatie over streams in .NET.

Notitie

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

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 te garanderen voor niet-zoekbare streamuploads, bufferen de Storage-clientbibliotheken 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 MaximumTransferSize, zelfs bij het uploaden in volgorde. Als u de waarde verlaagt, MaximumTransferSize 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 MaximumTransferSize de buffertijd en kan dit leiden tot betere prestaties.

Een ander scenario waarin buffering plaatsvindt, is wanneer u gegevens uploadt met parallelle REST-aanroepen om de netwerkdoorvoer te maximaliseren. De clientbibliotheken hebben bronnen nodig die ze parallel kunnen lezen en omdat streams opeenvolgend zijn, bufferen de opslagclientbibliotheken de gegevens voor elke afzonderlijke REST-aanroep voordat ze beginnen met uploaden. Dit buffergedrag treedt zelfs op als de opgegeven stroom kan worden gezocht.

Als u buffering wilt voorkomen tijdens een asynchrone uploadaanroep, moet u een zoekbare stream opgeven en instellen MaximumConcurrency op 1. Hoewel deze strategie in de meeste situaties moet werken, is het nog steeds mogelijk om buffering uit te voeren als uw code gebruikmaakt van andere clientbibliotheekfuncties waarvoor buffering is vereist.

InitialTransferSize bij uploaden

Wanneer een doorzoekbare stream wordt opgegeven voor uploaden, wordt de lengte van de stroom gecontroleerd op basis van de waarde van InitialTransferSize. Als de lengte van de stream kleiner is dan deze waarde, wordt de hele stream geüpload als één REST-aanroep, ongeacht andere StorageTransferOptions waarden. Anders wordt het uploaden uitgevoerd in meerdere onderdelen, zoals eerder beschreven. InitialTransferSize heeft geen effect op een niet-zoekbare stroom en wordt genegeerd.

Prestatieoverwegingen voor downloads

Tijdens een download splitsen de Storage-clientbibliotheken een bepaalde downloadaanvraag in meerdere subdownloads op basis van de waarden die in het StorageTransferOptions exemplaar 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.

Bufferen tijdens downloads

Het ontvangen van meerdere HTTP-antwoorden tegelijk met de inhoud van de hoofdtekst heeft gevolgen voor het geheugengebruik. De Storage-clientbibliotheken voegen echter niet expliciet een bufferstap toe voor gedownloade inhoud. Binnenkomende antwoorden worden op volgorde verwerkt. De clientbibliotheken configureren een buffer van 16 kilobyte voor het kopiëren van streams van een HTTP-antwoordstroom naar een door de aanroeper verstrekte doelstroom of bestandspad.

InitialTransferSize bij downloaden

Tijdens een download maken de Storage-clientbibliotheken één aanvraag voor het downloadbereik die wordt gebruikt InitialTransferSize 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 MaximumTransferSize de volledige download is voltooid.

Volgende stappen