Dela via

Prestandajustering för uppladdningar och nedladdningar med Go

  • Artikel

När ett program överför data med hjälp av Azure Storage-klientbiblioteket för Go finns det flera faktorer som kan påverka hastigheten, minnesanvändningen och till och med om begäran lyckades eller misslyckades. 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 egenskaper. 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

Om den totala blobstorleken är mindre än eller lika med 256 MB laddas data upp med en enda Put Blob-begäran . Om blobstorleken är större än 256 MB, eller om blobstorleken är okänd, laddas bloben upp i segment med hjälp av en serie Put Block-anrop följt av Placera blockeringslista.

Följande egenskaper kan konfigureras och finjusteras baserat på appens behov:

  • BlockSize: Den maximala längden på en överföring i byte när du laddar upp en blockblob i segment. Standardvärdet är 4 MB.
  • Concurrency: Det maximala antalet undertransfers som kan användas parallellt. Standardvärdet är 5.

De här konfigurationsalternativen är tillgängliga när du laddar upp med hjälp av följande metoder:

Metoden Upload stöder inte dessa alternativ och laddar upp data i en enda begäran.

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ö.

Blockera storlek

Argumentet BlockSize är den maximala längden på en överföring i byte vid uppladdning av en blockblob i segment.

För att hålla data i rörelse effektivt kanske klientbiblioteken inte alltid når BlockSize 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

I följande kodexempel visas hur du definierar värden för en UploadFileOptions-instans och skickar dessa konfigurationsalternativ som en parameter till UploadFile.

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.

func uploadBlobWithTransferOptions(client *azblob.Client, containerName string, blobName string) {
    // Open the file for reading
    file, err := os.OpenFile("path/to/sample/file", os.O_RDONLY, 0)
    handleError(err)

    defer file.Close()

    // Upload the data to a block blob with transfer options
    _, err = client.UploadFile(context.TODO(), containerName, blobName, file,
        &azblob.UploadFileOptions{
            BlockSize:   int64(8 * 1024 * 1024), // 8 MiB
            Concurrency: uint16(2),
        })
    handleError(err)
}

I det här exemplet anger vi antalet parallella överföringsarbetare till 2 med hjälp av fältet Concurrency . Den här konfigurationen öppnar upp till två anslutningar samtidigt, vilket gör att uppladdningen kan ske parallellt. Om blobstorleken är större än 256 MB laddas blobben upp i segment med en maximal segmentstorlek på 8 MiB, enligt fältets Block_Size inställningar.

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. 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 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 BlockSize, även när du laddar upp i sekvens. Om du minskar värdet för BlockSize 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 upplever frekventa timeouter under dataöverföringar av en viss storlek minskar en minskning av BlockSize värdet för buffringstiden och kan resultera i bättre prestanda.

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 egenskaper.

Ange överföringsalternativ för nedladdningar

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

  • BlockSize: Den maximala segmentstorleken som används för att ladda ned en blob. Standardvärdet är 4 MB.
  • Concurrency: Det maximala antalet undertransfers som kan användas parallellt. Standardvärdet är 5.

De här alternativen är tillgängliga när du laddar ned med hjälp av följande metoder:

Metoden DownloadStream stöder inte dessa alternativ och laddar ned data i en enda begäran.

Kodexempel

I följande kodexempel visas hur du definierar värden för en DownloadFileOptions-instans och skickar dessa konfigurationsalternativ som en parameter till DownloadFile.

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.

func downloadBlobTransferOptions(client *azblob.Client, containerName string, blobName string) {
    // Create or open a local file where we can download the blob
	file, err := os.Create("path/to/sample/file")
	handleError(err)

	// Download the blob to the local file
	_, err = client.DownloadFile(context.TODO(), containerName, blobName, file,
		&azblob.DownloadFileOptions{
			BlockSize:   int64(4 * 1024 * 1024), // 4 MiB
			Concurrency: uint16(2),
		})
	handleError(err)
}

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.

Relaterat innehåll