Blob 儲存體的效能和延展性檢查清單
Microsoft 開發了一些實證做法，以便使用 Blob 儲存體開發高效能應用程式。 此檢查清單會識別可供開發人員遵循以將效能最佳化的重要做法。 在設計應用程式時和整個過程中，請記住這些做法。
Azure 儲存體具有容量、交易速率和頻寬的延展性和效能目標。 如需 Azure 儲存體帳戶延展性目標的詳細資訊，請參閱標準儲存體帳戶的延展性與效能目標及 Blob 儲存體的延展性與效能目標。
檢查清單
本文會將效能實證做法整理成一份檢查清單，供您在開發 Blob 儲存體應用程式時遵循檢查。
| 完成 | 類別 | 設計考量 |
|---|---|---|
| 延展性目標 | 您是否可以將應用程式設計成使用的儲存體帳戶數目不超過上限？ | |
| 延展性目標 | 您是否要避免接近容量和交易限制？ | |
| 延展性目標 | 有大量用戶端並行存取單一 blob 嗎？ | |
| 延展性目標 | 應用程式是否在單一 blob 的延展性目標內？ | |
| 資料分割 | 您的命名慣例設計能因應更好的負載平衡嗎？ | |
| 網路 | 用戶端裝置是否有足夠高的頻寬和足夠低的延遲，以達到所需的效能？ | |
| 網路 | 用戶端裝置是否有高品質網路連結？ | |
| 網路 | 用戶端應用程式是否位於與儲存體帳戶相同的區域中？ | |
| 直接用戶端存取 | 您是否使用共用存取簽章 (SAS) 和跨原始資源共用 (CORS) 來啟用 Azure 儲存體的直接存取？ | |
| 快取功能 | 您的應用程式快取資料是否經常存取且很少變更？ | |
| 快取功能 | 您的應用程式是否會在用戶端快取更新，然後以較大的集合上傳，以此方式分批處理更新？ | |
| .NET 組態 | 您是否已設定用戶端使用足夠數量的並行連線？ | |
| .NET 組態 | 針對 .NET 應用程式，您是否已設定 .NET 使用足夠數量的執行緒？ | |
| 平行處理原則 | 您是否已確保平行處理原則已適當地受到限制，因此您不會讓用戶端功能超載或接近延展性目標？ | |
| 工具 | 您是否使用 Microsoft 所提供的最新用戶端程式庫和工具版本？ | |
| 重試 | 您是否針對節流錯誤和逾時使用重試原則搭配指數輪詢？ | |
| 重試 | 您的應用程式是否避免重試不能再嘗試的錯誤？ | |
| 複製 Blob | 您是否以最有效率的方式複製 Blob？ | |
| 複製 Blob | 您是否使用最新版的 AzCopy 執行大量複製作業？ | |
| 複製 Blob | 您是否使用 Azure 資料箱系列來匯入大量資料？ | |
| 內容發佈 | 您是否會使用 CDN 進行內容發佈？ | |
| 使用中繼資料 | 您是否將 Blob 相關的常用中繼資料儲存在它的中繼資料內？ | |
| 服務中繼資料 | 允許時間用於帳戶和容器中繼資料傳播 | |
| 效能微調 | 您是否主動微調用戶端程式庫選項，以最佳化資料傳輸效能？ | |
| 快速上傳 | 嘗試快速上傳一個 Blob 時，您是否平行上傳區塊？ | |
| 快速上傳 | 嘗試快速上傳多個 Blob 時，您是否平行上傳 Blob？ | |
| Blob 類型 | 您是否在適當的時機使用分頁 Blob 或區塊 Blob？ |
延展性目標
如果您的應用程式達到或超過任何延展性目標，它可能會遇到增加的交易延遲或節流。 當 Azure 儲存體對您的應用程式進行節流時，該服務會開始傳回 503 (伺服器忙碌) 或 500 (作業逾時) 錯誤碼。 保持在延展性目標的限制範圍內以避免這些錯誤，對於提升應用程式效能很重要。
如需佇列服務的延展性目標詳細資訊，請參閱 Azure 儲存體延展性和效能目標。
儲存體帳戶的數目上限
如果您即將達到特定訂用帳戶/區域組合允許的儲存體帳戶數目上限，請評估您的案例，並判斷是否適用下列任何條件：
- 您是使用儲存體帳戶來儲存非受控磁碟，並將這些磁碟新增至您的虛擬機器 (VM) 嗎？ 在此案例中，Microsoft 建議使用受控磁碟。 受控磁碟會自動調整規模，而不需要建立及管理個別的儲存體帳戶。 如需詳細資訊，請參閱 Azure 受控磁碟簡介
- 是否每個客戶使用一個儲存體帳戶，以達資料隔離的目的？ 在此案例中，Microsoft 建議每個客戶 (而不是整個儲存體帳戶) 使用一個 blob 容器。 Azure 儲存體現在可讓您按照每個容器指派 Azure 角色。 如需詳細資訊，請參閱指派 Azure 角色以存取 Blob 資料。
- 您是否使用多個儲存體帳戶來分區，以增加輸入、輸出、每秒的 I/O 作業 (IOPS) 或容量？ 在此案例中，可能的話，我們建議您善用提高儲存體帳戶的限制，以降低您的工作負載所需的儲存體帳戶數目。 請連絡 Azure 支援來要求提高儲存體帳戶的限制。
容量和交易目標
如果您的應用程式即將達到單一儲存體帳戶的延展性目標，您可以考慮採用下列其中一個方法：
- 如果您的應用程式達到交易目標，請考慮使用區塊 blob 儲存體帳戶，這些帳戶已最佳化高交易率和低延遲與一致延遲。 如需詳細資訊，請參閱 Azure 儲存體帳戶概觀。
- 重新思考會造成您的應用程式達到或超出延展性目標的工作負載。 您是否能夠以不同的方式設計工作負載，以使用較少的頻寬或容量或使用較少的交易？
- 如果您的應用程式必須超出其中一個延展性目標，則建立多個儲存體帳戶，並將您的應用程式資料在這幾個儲存體帳戶中進行分割。 如果您要使用此模式，那麼請確定設計您的應用程式，以便日後可以增加更多儲存體帳戶以取得負載平衡。 除了儲存資料、進行交易或傳輸資料等使用方式外，儲存體帳戶本身不會有其他費用。
- 如果您的應用程式很接近頻寬目標，請考慮在用戶端壓縮資料，以便降低將資料傳送至 Azure 儲存體所需的頻寬。 雖然壓縮資料可節省頻寬並改善網路效能，但也可能對效能造成負面影響。 針對用戶端上資料壓縮和解壓縮，評估額外處理需求所造成的效能影響。 請記住，儲存壓縮的資料可能會使疑難排解變得更困難，因為使用標準工具來檢視資料可能更具挑戰性。
- 如果您的應用程式很接近延展性目標，則務必使用指數輪詢進行重試。 最好是藉由實作本文所述的建議，嘗試避免達到延展性目標。 不過，使用指數輪詢進行重試會讓您的應用程式無法快速重試，這可能會使節流變差。 如需詳細資訊，請參閱逾時和伺服器忙碌錯誤一節。
並行存取單一 blob 的多個用戶端
如果您有大量的用戶端並行存取單一 blob，則必須考慮每個 blob 和儲存體帳戶的延展性目標。 可以存取單一 blob 的用戶端確切數目，會視各種因素而有所不同，例如，同時要求 blob 的用戶端數目、blob 的大小、網路狀況等等。
如果可以透過 CDN 散發 blob (例如從網站提供的影像或視訊)，則您可以使用 CDN。 如需詳細資訊，請參閱標題為內容發佈章節。
在其他情況下 (例如機密資料的科學模擬)，您有兩個選擇。 第一個選擇是以錯開您工作負載的存取，比較經過一段時間後存取 blob 以及同時存取 blob 的不同。 此外，您也可以將 blob 暫時複製到多個儲存體帳戶，以增加每個 blob 以及所有儲存體帳戶上的 IOPS 總數。 結果會依您的應用程式行為而有所不同，因此請務必在設計期間測試並行模式。
每個 Blob 的頻寬和作業
單一 Blob 每秒支援高達 500 個要求。 如果您有多個用戶端需要讀取相同的 blob，而且您可能超過此限制，請考慮使用區塊 blob 儲存體帳戶。 區塊 blob 儲存體帳戶會提供較高的要求率或每秒 I/O 作業數 (IOPS)。
您也可以使用內容傳遞網路 (CDN)，例如 Azure CDN，在 blob 上散發作業。 如需 Azure CDN 的詳細資訊，請參閱 Azure CDN 概觀。
資料分割
了解 Azure 儲存體分割 blob 資料的方式，有助於提高效能。 相較於提供分散在多個分割區的資料，Azure 儲存體提供單一分割區中資料的速度要快得多。 適當地命名 blob，您可以提升讀取要求的效率。
Azure 儲存體使用範圍型資料分割配置來進行調整規模和負載平衡。 每個 blob 都有一個分割區索引鍵，其中包含完整的 blob 名稱 (帳戶 + 容器 + blob)。 分割區索引鍵是用來將 blob 資料分割成不同範圍。 然後，範圍會在 Blob 儲存體之間取得負載平衡。
範圍型資料分割表示使用語彙排序的命名慣例 (例如 mypayroll、myperformance、myemployees 等)，或使用時間戳記 (log20160101、log20160102、log20160102 等) 更可能會導致分割區在相同的分割區伺服器上進行共置，直到增加的負載須將分割區分割成更小的範圍。 Blob 並存於相同的分割區伺服器可增強效能，因此以最有效率的方式來組織這些命名 blob，是效能強化的重要一環。
例如，容器內的所有 Bob 接受單一伺服器的服務，直到這些 Blob 的負載需要進一步重新平衡分割區範圍。 同樣地，一群名稱依語彙順序排列的少量負載帳戶可能接受單一伺服器的服務，直到其中一個或所有帳戶的負載要求它們分割到多個分割區伺服器。
每個負載平衡作業都可能在作業期間影響儲存體呼叫的延遲。 服務處理某個分割區流量突然暴增的能力，會受到單一分割區伺服器延展性的限制，直到負載平衡作業著手重新平衡分割區索引鍵範圍。
您可以遵循一些最佳做法來降低這類作業的頻率。
可能的話，請針對標準和進階儲存體帳戶使用大於 256 KiB 的 Blob 或區塊大小。 較大的 blob 或區塊大小會自動啟用高輸送量區塊 blob。 高輸送量區塊 blob 提供不受分割區命名影響的高效能擷取。
請檢查您用於帳戶、容器、Blob、資料表和佇列的命名慣例。 請考慮使用最符合您需求的雜湊函式，並在帳戶、容器或 Blob 名稱前面加上三位數雜湊。
如果使用時間戳記或數字識別碼組織資料，請確定您使用的不是僅附加在後 (或僅在前面附加) 的流量模式。 這些模式不適用於以範圍為基礎的分割系統。 這些模式可能會導致所有流量進入單一分割區，並限制系統無法達成有效的負載平衡。
例如，如果日常作業使用有時間戳記的 blob，如 yyyymmdd，則該日常作業的所有流量都會導向至由單一分割區伺服器服務的單一 blob。 請考慮每個 Blob 的限制和每個分割區的限制是否符合您的需求，考慮是否需要將這項作業拆分成多個 Blob。 同樣地，如果在資料表中儲存時間序列資料，則所有流量都可以導向到索引鍵命名空間的最後部分。 如果您使用數值識別碼，請在識別碼前面加上三位數的雜湊。 如果您使用時間戳，請在時間戳記前面加上秒值，例如 ssyyyymmdd。 如果應用程式定期執行列出和查詢作業，請選擇限制查詢次數的雜湊函數。 其他情況，隨機的前置詞即足以應付。
如需 Azure 儲存體所使用的資料分割配置詳細資訊，請參閱 Azure 儲存體：具有強一致性的高可用性雲端儲存體服務。
網路
應用程式的實體網路限制可能會對效能產生重大影響。 下列各節說明使用者可能會遇到的部分限制。
用戶端網路功能
如下列各節所述，網路連結的頻寬和品質在應用程式效能中扮演重要角色。
輸送量
頻寬的問題經常是用戶端的功能。 較大型的 Azure 執行個體擁有較大容量的 NIC，因此，如果您需要單一機器的較高網路限制，您應考慮使用較大型的執行個體或更多的 VM。 如果您從內部部署應用程式存取 Azure 儲存體，則適用相同的規則：了解用戶端裝置的網路功能和與 Azure 儲存體位置的網路連線能力，以及視需要進行改善或設計您的應用程式以便使用其功能。
連結品質
與任何網路使用方式一樣，請記住導致錯誤和封包遺失的網路狀況會減慢有效的輸送量。 使用 WireShark 或 NetMon 可能有助於診斷此問題。
Location
在任何分散式環境中，將用戶端放置於伺服器附近可提供最佳的效能。 若要以最低的延遲時間存取 Azure 儲存體，對用戶端而言的最佳位置是在同一個 Azure 區域內。 例如，如果您擁有使用 Azure 儲存體的 Azure Web 應用程式，則將這兩者置於單一區域內 (例如，美國西部或東南亞)。 共置資源可降低延遲和成本，因為單一區域內的頻寬使用量是免費的。
如果將存取 Azure 儲存體的用戶端應用程式不在 Azure 中託管 (例如行動裝置應用程式或內部部署企業服務)，則將儲存體帳戶置於這些用戶端附近的區域內可以降低延遲。 如果您的用戶端分佈廣闊 (例如，有些在北美洲，有些在歐洲)，則考慮在每個區域使用一個儲存體帳戶。 如果應用程式儲存的資料特定用於個別使用者，且不需要複寫儲存體帳戶之間的資料，則此方法較容易實作。
如需廣泛散發 blob 內容，請使用內容傳遞網路，例如 Azure CDN。 如需 Azure CDN 的詳細資訊，請參閱 Azure CDN。
SAS 和 CORS
假設您需要授權在使用者的網頁瀏覽器或在行動電話應用程式中執行的程式碼 (例如 JavaScript)，以存取 Azure 儲存體中的資料。 其中一種方法是建置可作為 Proxy 的服務應用程式。 使用者的裝置會向服務進行驗證，然後再授權存取 Azure 儲存體資源。 如此一來，您可以避免在未受到保護的裝置上公開您的儲存體帳戶金鑰。 不過，因為在使用者裝置與 Azure 儲存體之間轉送的所有資料都必須通過服務應用程式，所以此方法會在服務應用程式上加上顯著負荷。
使用共用存取簽章 (SAS)，即可避免使用服務應用程式作為 Azure 儲存體的 Proxy。 使用 SAS，您可以藉由使用有限的存取權杖，讓使用者的裝置能直接對 Azure 儲存體提出要求。 例如，如果使用者想要將相片上傳至您的應用程式，則您的服務應用程式可以產生 SAS，並將它傳送到使用者的裝置。 SAS 權杖可以授與在指定的時間間隔內寫入 Azure 儲存體資源的權限，該時間間隔後 SAS 權杖就會過期。 如需關於 SAS 的詳細資訊，請參閱使用共用存取簽章 (SAS) 對 Azure 儲存體資源授與有限存取權。
通常，在某個網域上由網站託管的頁面中，網頁瀏覽器不允許 JavaScript 對另一個網域執行特定作業 (例如寫入作業)。 這項原則稱為同源原則，可防止某頁上的惡意程式碼取得另一個網頁上資料的存取權。 不過，在雲端建置解決方案時，同源原則會是一項限制。 跨原始資源共用 (CORS) 是一項瀏覽器功能，可讓目標網域與信任源自來源網域之要求的瀏覽器進行通訊。
例如，假設在 Azure 中執行的 Web 應用程式向 Azure 儲存體帳戶提出資源要求。 Web 應用程式是來源網域，而儲存體帳戶是目標網域。 您可以為任何 Azure 儲存體服務設定 CORS，以便與網頁瀏覽器進行通訊，而該網頁瀏覽器會向 Azure 儲存體所信任的來源網域提出要求。 如需 CORS 的詳細資訊，請參閱 Azure 儲存體的跨原始資源共用 (CORS) 支援。
SAS 和 CORS 都可協助您避免 Web 應用程式上不必要的負載。
快取功能
快取在效能方面扮演重要的角色。 下列各節說明快取的最佳做法。
讀取資料
一般情況下，讀取資料一次比讀取兩次好。 請考慮 Web 應用程式範例：從 Azure 儲存體擷取 50 MiB blob，當成內容提供給使用者。 在理想的情況下，應用程式會在本機將 blob 快取到磁碟，然後針對後續的使用者要求擷取快取的版本。
如果 blob 自快取之後都不曾經過修改，則避免擷取 blob 的其中一種方式，就是使用條件式標頭來限定 GET 作業的修改時間。 如果上次修改時間是在 blob 快取的時間之後，則會擷取 blob 並重新快取。 否則，會擷取快取的 blob 以獲得最佳效能。
您也可以決定應用程式的設計前提是假設 blob 在擷取之後的短期內保持不變。 在此情況下，應用程式就不需要檢查在該間隔期間內 blob 是否經過修改。
應用程式經常使用的設定資料、查閱資料和其他資料，都是適合快取的候選項目。
如需使用條件式標頭的詳細資訊，請參閱指定 Blob 服務作業的條件式標頭。
以批次方式上傳資料
在某些情況下，您可以在本機彙總資料，然後以批次方式將它定期上傳，而非立即上傳每一份資料。 例如，假設 Web 應用程式保留活動的記錄檔。 應用程式可以在每個活動發生時將其詳細資料上傳到資料表 (這需要許多儲存作業)，或將活動詳細資料儲存至本機記錄檔，然後定期將所有活動詳細資料以分隔檔案的形式上傳到 blob。 如果每個記錄項目的大小是 1 KB，您可以在單一交易中上傳數千個項目。 單一交易支援上傳的 blob 大小上限為 64 MiB。 應用程式開發人員在設計時必須考慮用戶端裝置或上傳失敗的可能性。 如果需要下載一段時間間隔的活動資料而不是單一活動，則建議使用 Blob 儲存體，而不要使用資料表儲存體。
.NET 組態
對於使用 .NET Framework 的專案，本節會列出一些可用來大幅改善效能的快速組態設定。 如果使用 .NET 以外的其他語言，請查看類似的概念是否適用於您所選擇的語言。
提高預設的連線限制
注意
本節適用於使用 .NET Framework 的專案，因為連線共用是由 ServicePointManager 類別所控制。 .NET Core 引進了連線集區管理的重大變更，其中連線共用發生在 HttpClient 層級，且依預設不會限制集區大小。 這表示 HTTP 連線會自動調整以符合您的工作負載。 建議您盡可能使用最新版本的 .NET，以利用效能增強功能。
對於使用 .NET Framework 的專案，您可以使用下列程式碼來增加預設連線限制 (此值在用戶端環境中通常為二，或在伺服器環境中通常為十) 提高到 100。 一般而言，您應將此值大約設為應用程式所使用的執行緒數量。 在開啟任何連線之前設定連線限制。
ServicePointManager.DefaultConnectionLimit = 100; //(Or More)
若要深入了解 .NET Framework 中的連線集區限制，請參閱 .NET Framework 連線集區限制和全新的 Azure SDK for .NET。
若是其他程式設計語言，請參閱文件以確定如何設定連線限制。
提高執行緒數目上限
如果您同時使用同步呼叫與非同步工作，則可增加執行緒集區中的執行緒數目：
ThreadPool.SetMinThreads(100,100); //(Determine the right number for your application)
如需詳細資訊，請參閱 ThreadPool.SetMinThreads 方法。
無限制的平行處理原則
雖然平行處理原則很適合用於效能，但請小心使用無限制的平行處理原則，這表示執行緒或平行要求數目並未強加任何限制。 請務必將平行要求限制為上傳或下載資料、存取相同儲存體帳戶中的多個資料分割，或存取相同資料分割中的多個項目。 如果平行處理原則沒有限制，則您的應用程式可超出用戶端裝置的功能或儲存體帳戶的延展性目標，因而產生較長的延遲與節流作業。
用戶端程式庫和工具
為了達到最佳效能，請一律使用 Microsoft 所提供的最新用戶端程式庫和工具。 Azure 儲存體的用戶端程式庫適用於各種不同的語言。 Azure 儲存體也支援 PowerShell 和 Azure CLI。 Microsoft 主動開發以效能為考量的這些用戶端程式庫和工具，透過最新的服務版本將他們保持在最新的狀態，並確保這些工具會在內部處理許多已經實證的效能做法。
提示
ABFS 驅動程式的設計訴求，是要克服 WASB 固有的缺點。 Microsoft 建議透過 WASB 驅動程式使用 ABFS 驅動程式，因為 ABFS 驅動程式特別針對巨量資料分析進行最佳化。
處理服務錯誤
當服務無法處理要求時，Azure 儲存體會傳回錯誤。 了解特定案例中 Azure 儲存體可能傳回的錯誤，對於效能最佳化很有幫助。 如需常見錯誤碼的清單，請參閱常見 REST API 錯誤碼。
逾時和伺服器忙碌錯誤
如果您的應用程式很接近延展性限制，Azure 儲存體可能進行節流處理。 在某些情況下，Azure 儲存體可能因某些暫時性狀況而無法處理要求。 在這兩種情況下，服務可能會傳回 503 (伺服器忙碌) 或500 (逾時) 錯誤。 如果服務正在重新平衡資料分割，以允許更高的輸送量，也可能會發生這些錯誤。 用戶端應用程式通常應該重試導致其中一個錯誤的作業。 不過，如果 Azure 儲存體因為您的應用程式超出延展性目標而進行節流，或即使服務因為一些其他原因而無法服務要求，則積極重試的結果可能會使問題雪上加霜。 建議使用指數輪詢重試原則，且用戶端程式庫會預設為此行為。 例如，您的應用程式可能會 2 秒、4 秒、10 秒、30 秒後重試，然後完全放棄。 如此一來，您的應用程式會大幅降低其在服務上的負荷，而不會使導致節流的行為惡化。
因為連線能力錯誤不是節流的結果，且被認為是暫時性的，因此可以立即重試連線能力錯誤。
無法重試的錯誤
用戶端程式庫會在認知哪些錯誤可以重試和哪些錯誤不能重試的情況下，處理重試。 不過，如果您直接呼叫 Azure 儲存體 REST API，就會發生一些您不得重試的錯誤。 例如，400 (不正確的要求) 錯誤表示用戶端應用程式傳送了無法處理的要求，因為該要求不是預期的格式。 每次重新傳送此要求都會產生相同的回應，所以重試並沒有用。 如果您直接呼叫 Azure 儲存體 REST API，請注意可能發生的錯誤，以及是否應該重試。
如需 Azure 儲存體錯誤碼的詳細資訊，請參閱狀態和錯誤碼。
複製與移動 Blob
Azure 儲存體提供數種解決方案，可在儲存體帳戶內、在儲存體帳戶之間，以及在內部部署系統與雲端之間複製和移動 blob。 本節將說明部分選項在效能方面的影響。 如需以高效率方式將資料轉送至 Blob 儲存體或從中傳送資料的詳細資訊，請參閱選擇適合資料轉送的 Azure 解決方案。
Blob 複製 API
若要跨儲存體帳戶複製 blob，請使用從 URL 放置區塊作業。 此作業會將資料從任何 URL 來源同步複製到區塊 blob。 當您跨儲存體帳戶移轉資料時，使用 Put Block from URL 作業可以大幅減少所需的頻寬。 由於複製作業會在服務端進行，因此您不需要下載資料並重新上傳。
若要複製相同儲存體帳戶內的資料，請使用複製 Blob 作業。 複製相同儲存體帳戶內的資料通常會快速完成。
使用 AzCopy
AzCopy 命令列公用程式是一種簡單且有效率的選項，可在儲存體帳戶中接收和傳送大量 blob，也可以跨儲存體帳戶大量轉送 blob。 AzCopy 已針對此案例進行最佳化，且可達到高傳輸率。 AzCopy 第 10 版會使用 Put Block From URL 作業來跨儲存體帳戶複製 blob 資料。 如需詳細資訊，請參閱使用 AzCopy v10 將資料複製或移動至 Azure 儲存體。
使用 Azure 資料箱
若要將大量資料匯入至 Blob 儲存體，請考慮使用 Azure 資料箱系列進行離線傳輸。 當您受到時間、網路可用性或成本限制時，適合使用 Microsoft 提供的資料箱裝置，將大量資料移動到 Azure。 如需詳細資訊，請參閱 Azure 資料箱文件。
內容發佈
有時，應用程式需要提供相同的內容給位於相同或多個區域中的多位使用者，例如，網站首頁上所用的產品示範影片。 在此案例中，請使用內容傳遞網路 (CDN)，例如 Azure Front Door。 Azure Front Door 是 Microsoft 的新式雲端 CDN，可以在您的使用者和世界各地應用程式的靜態和動態網路內容之間，提供快速、可靠且安全的存取。 Azure Front Door 會使用 Microsoft 的全域邊緣網路以及數百個全域和本機存在點 (PoP) 來提供 Blob 儲存體內容。 CDN 通常可支援比單一儲存體帳戶更高的輸出限制，並改善向其他區域傳遞內容的延遲。
如需 Azure Front Door 的詳細資訊，請參閱 Azure Front Door。
使用中繼資料
Blob 服務支援 HEAD 要求，其中可包含 Blob 屬性或中繼資料。 例如，如果您的應用程式需要相片的 Exif (可交換影像格式) 資料，則可以擷取該相片並解壓縮。 為了節省頻寬並提高效能，您的應用程式可以在應用程式上傳相片時，將 Exif 資料儲存在 blob 的中繼資料中。 然後，您可以只使用 HEAD 要求，在中繼資料中擷取 Exif 資料。 只擷取中繼資料而不是 blob 的完整內容，可節省大量頻寬並減少解壓縮 Exif 資料所需的處理時間。 請記住，每個 blob 可以儲存 8 KiB 的中繼資料。
帳戶和容器中繼資料更新
帳戶和容器中繼資料會傳播到帳戶所在區域中的儲存體服務。 視作業而定，此中繼資料的完整傳播最多可能需要 60 秒。 例如：
- 如果您快速建立、刪除和重新建立位於相同區域中相同帳戶名稱的帳戶，請確保等候 60 秒以便讓帳戶狀態完全傳播，否則您的要求可能會失敗。
- 當您在容器上建立儲存的存取原則時，該原則可能需要 30 秒才會生效。
資料傳輸的效能微調
當應用程式使用 Azure 儲存體用戶端程式庫傳輸資料時，有幾個因素可能會影響速度、儲存體使用量，甚至是要求的成功或失敗。 若要將資料傳輸的效能和可靠性最大化，請務必根據應用程式執行所在的環境主動設定用戶端程式庫傳輸選項。 若要深入了解，請參閱上傳和下載的效能微調。
快速上傳 Blob
若要快速上傳 blob，請先判斷您要上傳的是一個 blob 或多個 blob。 使用下列指引，根據您的案例來判斷所要使用的正確方法。 如果您使用 Azure 儲存體用戶端程式庫進行資料傳輸，請參閱資料傳輸的效能微調以取得進一步指引。
快速上傳一個大型 Blob
若要快速上傳單一大型 Blob，用戶端應用程式可平行上傳其區塊或分頁。請留意個別 Blob 和儲存體帳戶整體的延展性目標。 Azure 儲存體用戶端程式庫支援平行上傳。 其他支援語言的用戶端程式庫會提供類似的選項。
快速上傳多個 Blob
若要快速上傳多個 Blob，請平行上傳 Blob。 因為平行上傳會將上傳散佈到儲存體服務的多個資料分割區，因此會比使用平行區塊上傳一次上傳一個 Blob 的方法要快。 AzCopy 依預設會執行平行上傳，在此案例中我們建議使用此方法。 如需詳細資訊，請參閱開始使用 AzCopy。
選擇 Blob 的正確類型
Azure 儲存體支援區塊 Blob、附加 Blob 和分頁 Blob。 在指定使用的案例中，您的 Blob 類型選擇會影響解決方案的效能和延展性。
當您想要有效率地上傳大量資料時，區塊 blob 是適合的選擇。 例如，將相片或影片上傳至 Blob 儲存體的用戶端應用程式，會以區塊 blob 為目標。
附加 blob 和區塊 blob 類似，都是由區塊所組成。 當您修改附加 blob 時，區塊只會新增至該 blob 的尾端。 當應用程式需要將資料新增至現有的 blob 時，在需要記錄之類的情況下，適合使用附加 blob。
如果應用程式需要對資料執行隨機寫入，則適合使用分頁 blob。 例如，Azure 虛擬機器磁碟會儲存為分頁 Blob。 如需詳細資訊，請參閱了解區塊 Blob、附加 Blob 和分頁 Blob。