利用此檢查清單來降低延遲、提升吞吐量，並與 Azure 儲存規模與效能目標保持一致。 Azure Storage 使用「 目標 」而非 「限制 」這個詞，因為某些數值可依需求調整。 當用戶端接近或超過這些目標時，Azure Storage 可能會限制請求，導致延遲增加。 請使用本文的檢查清單，在不犧牲效能的前提下，與目標對齊。
備註
本文僅適用於自訂應用程式。 關於適用於所有客戶端的建議，請參閱 Blob 儲存的效能檢查清單。
效能檢查清單
使用 Azure Storage 用戶端函式庫：為了最佳效能，請使用 Microsoft 用戶端函式庫。 這些函式庫經過效能優化，持續更新服務版本，並在內部處理經過驗證的效能實務。
優化平行區塊傳輸：以較小區塊大小增加平行傳輸，但保持大小高於 4 MiB（標準）或 256 KiB（高級區塊），以啟動高吞吐量區塊塊。 平衡平行性以避免超出裝置容量或儲存目標，因而導致節流。 對同時請求設定適當的限制。 請參閱 .NET、 Java、 JavaScript、 Python 和 Go 的效能指引。
使用指數退回重試策略：以指數退換策略處理暫時錯誤。 例如，在2、4、10、30秒後重試，然後停止。 此政策可防止因非暫時性錯誤而過度重試，例如應用程式接近或超越效能與擴展目標時所發生的錯誤。 客戶端函式庫知道哪些錯誤該重試，哪些錯誤不該重試。 要套用重試政策，請參閱 .NET、 Java、 JavaScript、 Python 和 Go 的重試指引。
使用伺服器對伺服器的 API 在容器與帳號間複製：使用Put Block From URL 來複製帳號間的資料，以及帳號內的資料。 伺服器端操作會降低頻寬，因為你不需要先下載再上傳資料。 請參閱 .NET、 Java、 JavaScript、 Python 和 Go 的文案指引。
快取資料以提升效能：快取頻繁存取或很少更改的資料，如設定與查詢資料。 使用條件式標頭搭配 GET 作業，以只在自上次快取後有修改時才擷取 Blob。 如需詳細資訊，請參閱指定 Blob 服務作業的條件式標頭。
分批上傳資料：在上傳前先彙整資料，而非立即上傳。 例如，可以將日誌儲存在本地，並定期作為單一區塊上傳，而不是分別上傳每個條目。