共用方式為

使用 Go 上傳和下載的效能微調

  • 發行項

當應用程式使用適用於 Go 的 Azure 儲存體 用戶端連結庫傳輸數據時，有幾個因素可能會影響速度、記憶體使用量，甚至是要求的成功或失敗。 若要將資料傳輸的效能和可靠性最大化，請務必根據應用程式執行所在的環境主動設定用戶端程式庫傳輸選項。

本文會逐步解說微調資料傳輸選項的幾個考量。 正確調整時，用戶端程式庫可以有效率地將資料分散到多個要求，進而改善作業速度、儲存體使用量和網路穩定性。

上傳的效能微調

正確調整資料傳輸選項是上傳可靠效能的關鍵。 記憶體傳輸會根據這些屬性的值分割成數個子傳輸。 支援的傳輸大小上限會因作業和服務版本而異，因此請務必檢查文件以判斷限制。 如需 Blob 儲存體傳輸大小限制的詳細資訊，請參閱調整 Blob 儲存體的目標。

設定上傳的傳輸選項

如果 Blob 大小總計小於或等於 256 MB，則會使用單 一 Put Blob 要求上傳數據。 如果 Blob 大小大於 256 MB，或 Blob 大小未知，則會使用一系列 Put Block 呼叫，後面接著放置區塊清單，以區塊方式上傳 Blob。

您可以根據應用程式的需求來設定及調整下列屬性：

  • BlockSize：在區塊中上傳區塊 Blob 時，以位元組為單位傳輸的最大長度。 預設值為 4 MB。
  • Concurrency：可以平行使用的子轉譯數目上限。 預設值為 5。

使用下列方法上傳時，可以使用這些組態選項：

Upload 方法不支援這些選項，並在單一要求中上傳數據。

注意

如果未提供，客戶端連結庫會針對每個數據傳輸選項使用預設值。 這些預設值通常在資料中心環境中更有效率，但可能不適合家庭消費者環境。 微調不佳的資料傳輸選項可能會導致作業時間太長，甚至要求逾時。 最好主動測試這些值，並根據應用程式和環境的需求來調整這些值。

BlockSize

BlockSize 引數是在區塊中上傳區塊 Blob 時，傳輸的最大長度 (以位元組為單位)。

為了保持移動資料有效率地，用戶端程式庫的每個傳輸不一定會達到 BlockSize 值。 視作業而定，傳輸大小支援的最大值可能會有所不同。 如需 Blob 儲存體傳輸大小限制的詳細資訊，請參閱調整 Blob 儲存體的目標中的圖表。

程式碼範例

下列程式代碼範例示範如何定義UploadFileOptions實例的值，並將這些組態選項當做參數傳遞至UploadFile。

此範例中提供的值並非旨在作為建議。 若要正確調整這些值，您必須考慮應用程式的特定需求。

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

在此範例中，我們會使用 Concurrency 字段，將平行傳輸背景工作角色的數目設定為 2。 此設定會同時開啟兩個連線，讓上傳可以平行進行。 如果 Blob 大小大於 256 MB，Blob 會以區塊大小上限為 8 MiB 的區塊上傳，如 字段所 Block_Size 設定。

上傳的效能考量

在上傳期間，儲存體用戶端程式庫會根據用戶端建構期間定義的設定選項，將指定的上傳資料流分割成多個子上傳。 每個子上傳都有自己的專屬 REST 作業呼叫。 儲存體用戶端程式庫會平行管理這些 REST 作業(視傳輸選項而定)，以完成完整上傳。

您可以在下列各節中了解用戶端程式庫如何處理緩衝處理。

注意

區塊 Blob 的最大區塊計數為 50,000 個區塊。 那麼，您的區塊 Blob 的大小上限為 50,000 x Block_Size。

上傳期間的緩衝處理

儲存體 REST 層不支援取得您離開的 REST 上傳作業；個別傳輸會是已完成或遺失。 為確保資料流上傳的復原能力，儲存體用戶端程式庫會先為每個個別 REST 呼叫緩衝處理資料，再開始上傳。 除了網路速度限制之外，此緩衝處理行為也是考量對 BlockSize 使用較小值的原因，即使依序上傳也是如此。 減少 BlockSize 的值會減少在每個要求上緩衝處理的資料量上限，以及每次重試失敗的要求。 如果您在特定大小的資料傳輸期間遇到頻繁逾時，減少 BlockSize 的值會減少緩衝處理時間，並可能導致更好的效能。

下載的效能微調

正確調整資料傳輸選項是下載可靠效能的關鍵。 記憶體傳輸會根據這些屬性的值分割成數個子傳輸。

設定下載的傳輸選項

您可以根據應用程式的需求來調整下列屬性：

  • BlockSize：用於下載 Blob 的最大區塊大小。 預設值為 4 MB。
  • Concurrency：可以平行使用的子轉譯數目上限。 預設值為 5。

使用下列方法下載時，可以使用這些選項：

DownloadStream 方法不支持這些選項，並在單一要求中下載數據。

程式碼範例

下列程式代碼範例示範如何定義 DownloadFileOptions 實例的值，並將這些組態選項當做參數傳遞至 DownloadFile。

此範例中提供的值並非旨在作為建議。 若要正確調整這些值，您必須考慮應用程式的特定需求。

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

下載的效能考量

在下載期間，儲存體用戶端程式庫會根據用戶端建構期間定義的設定選項，將指定的下載要求分割成多個子下載。 每個子下載都有自己的專屬 REST 作業呼叫。 視傳輸選項而定，用戶端程式庫會平行管理這些 REST 作業，以完成完整下載。

相關內容