使用 JavaScript 進行上傳和下載的效能微調

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

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

上傳效能調校

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

設定上傳的傳輸選項

您可以在 BlockBlobParallelUploadOptions 中設定屬性，以改善資料傳輸作業的效能。 下表列出您可以設定的屬性，以及描述：

maxSingleShotSize

maxSingleShotSize 值是單一要求上傳的 Blob 大小上限 (以位元組為單位)。

如果資料大小小於或等於 maxSingleShotSize，則會透過單一 Put Blob 請求上傳 Blob。 如果 Blob 的大小大於 maxSingleShotSize，或 Blob 的大小未知，則 Blob 會使用一系列的 Put Block 呼叫分塊上傳，然後接著使用 Put Block List。

務必注意，您為 blockSize 指定的值不會限制您為 maxSingleShotSize 定義的值。 maxSingleShotSize 引數會定義個別的大小限制，讓要求一次執行整個作業且沒有子傳輸。 通常您會希望 maxSingleShotSize 的大小至少與您為 blockSize 定義的值一樣大，甚至更大。 視資料傳輸的大小，此方法可能更有效率，因為傳輸是以單一要求完成，並避免多個要求的額外負荷。

如果您不確定哪個值最適合您的情況，安全的選項是將 maxSingleShotSize 設定為用於 blockSize 的相同值。

區塊大小

blockSize值是在以資料塊上傳區塊 Blob 時，每次傳輸的長度上限 (以位元組為單位)。

如先前所述，這個值不會限制 maxSingleShotSize，其可能大於 blockSize。

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

程式碼範例

下列程式碼範例顯示如何設定 BlockBlobParallelUploadOptions 值，並將選項包含作為上傳方法呼叫的一部分。 範例中提供的值並非意圖作為建議。 若要正確調整這些值，您必須考慮應用程式的特定需求。

// Specify data transfer options
const uploadOptions = {
  blockSize: 4 * 1024 * 1024, // 4 MiB max block size
  concurrency: 2, // maximum number of parallel transfer workers
  maxSingleShotSize: 8 * 1024 * 1024, // 8 MiB initial transfer size
} 

// Create blob client from container client
const blockBlobClient = containerClient.getBlockBlobClient(blobName);

// Upload blob with transfer options
await blockBlobClient.uploadFile(localFilePath, uploadOptions);

// Specify data transfer options
const uploadOptions: BlockBlobParallelUploadOptions = {
  blockSize: 4 * 1024 * 1024, // 4 MiB max block size
  concurrency: 2, // maximum number of parallel transfer workers
  maxSingleShotSize: 8 * 1024 * 1024, // 8 MiB initial transfer size
};

// Create blob client from container client
const blockBlobClient: BlockBlobClient = containerClient.getBlockBlobClient(blobName);

await blockBlobClient.uploadFile(localFilePath, uploadOptions);

在此範例中，我們使用 concurrency 屬性將平行傳輸工作程序的最大數量設為 2。 我們也會將 maxSingleShotSize 設定為 8 MiB。 如果 Blob 大小小於 8 MiB，則只需要單一要求即能完成上傳作業。 如果 Blob 大小大於 8 MiB，Blob 會以區塊上傳 (區塊大小上限為 4 MiB，這是我們在 blockSize 屬性所定義的)。

上傳的效能考量

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

上傳期間的緩衝處理

儲存體 REST 層不支援從您中斷的地方繼續 REST 上傳作業；個別傳輸不是完成，就是遺失。 為了確保串流上傳的韌性，儲存體用戶端程式庫會在開始上傳前，先為每個 REST 呼叫將資料緩衝起來。 除了網路速度限制之外，此緩衝處理行為也是考量對 blockSize 使用較小值的原因，即使依序上傳也是如此。 降低 blockSize 的值會減少每個請求以及每次重試失敗請求時所緩衝的資料量上限。 如果您在特定大小的資料傳輸期間遇到頻繁逾時，減少 blockSize 的值會減少緩衝處理時間，並可能導致更好的效能。

下載效能調校

只有在使用 downloadToBuffer 方法時，才能使用下載的微調資料傳輸選項。 此方法會根據 BlobDownloadToBufferOptions 中所定義的值，將 Blob 平行下載至緩衝區。 其他下載方法不支援微調資料傳輸選項。

設定下載的傳輸選項

使用 downloadToBuffer 方法時，可針對下載微調下列值：

• blockSize：為每個要求傳輸的區塊大小上限。
• concurrency：在任何指定時間發出的平行要求數目上限 (作為單一平行傳輸一部分)。

下載的效能考量

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

程式碼範例

下列程式碼範例示範如何設定 BlobDownloadToBufferOptions 的值，並在 downloadToBuffer 方法呼叫中包含選項。 範例中提供的值並非意圖作為建議。 若要正確調整這些值，您必須考慮應用程式的特定需求。

// Specify data transfer options
const downloadToBufferOptions = {
    blockSize: 4 * 1024 * 1024, // 4 MiB max block size
    concurrency: 2, // maximum number of parallel transfer workers
}

// Download data to buffer
const result = await client.downloadToBuffer(offset, count, downloadToBufferOptions);

// Specify data transfer options
const downloadToBufferOptions: BlobDownloadToBufferOptions = {
    blockSize: 4 * 1024 * 1024, // 4 MiB max block size
    concurrency: 2, // maximum number of parallel transfer workers
}

// Download data to buffer
const result = await client.downloadToBuffer(offset, count, downloadToBufferOptions);

與 CRC64-NVME 進行傳輸驗證

除了用 BlockBlobParallelUploadOptions 和 BlobDownloadToBufferOptions進行效能調校外，你還可以設定傳輸驗證，以驗證上傳和下載時的資料完整性。 雖然 CRC64-NVME 計算效能良好，但啟用傳輸驗證可能帶來效能影響，應與其他調校決策一併考量。

使用 CRC64-NVME 的傳輸驗證可為 Azure Blob 儲存體 提供用戶端層級的資料完整性，讓您可以驗證應用程式傳送的資料與儲存在 Azure 中並從中讀取的資料相同。 啟用時，Blob SDK 會在上傳與下載操作中計算並驗證 CRC64-NVME 校驗和，而服務則獨立計算並驗證 CRC64-NVME 校驗碼，以取得與回傳資料。 每次請求及整個資料流都會進行驗證，確保即使資料以區塊上傳或範圍讀取等分割傳輸，整個 blob 也能被驗證。 更多細節請參見 結構性身體格式 。

傳輸驗證選項可在用戶端層級使用 BlobClientConfig 定義，該系統對所有從 BlobClient 實例呼叫的方法套用驗證選項。 或者，你也可以在操作層級透過 BlobUploadOptions 或 BlobDownloadOptions 等選項來覆寫傳輸驗證選項。

const blobServiceClient = new BlobServiceClient(
   `https://${account}.blob.core.windows.net`,
   new DefaultAzureCredential(),
   {
     uploadContentChecksumAlgorithm: "StorageCrc64",
     downloadContentChecksumAlgorithm: "StorageCrc64",
   }
);

 const blobServiceClient: BlobServiceClient = new BlobServiceClient(
   `https://${account}.blob.core.windows.net`,
   new DefaultAzureCredential(),
   {
     uploadContentChecksumAlgorithm: "StorageCrc64",
     downloadContentChecksumAlgorithm: "StorageCrc64",
   },
);

相關內容

• 若要深入了解可能影響 Azure 儲存體作業效能的因素，請參閱 Blob 儲存體中的延遲。
• 若要查看針對使用 Blob 儲存體的應用程式最佳化效能的設計考量清單，請參閱 Blob 儲存體的效能和延展性檢查清單。