速率和使用量限制
Azure DevOps Services
Azure DevOps Services 使用多租用戶來降低成本並改善效能。 此設計可讓使用者容易受到效能問題的影響，甚至當其共用資源其他使用者的耗用量激增時，甚至中斷。 因此，Azure DevOps 會限制個人可以取用的資源，以及他們可以對特定命令提出的要求數量。 超過這些限制時，未來要求可能會延遲或封鎖。
如需詳細資訊，請參閱 Git 限制 和 最佳做法，以避免達到速率限制。
全域耗用量限制
Azure DevOps 目前具有全域耗用量限制，當共用資源處於不堪重負的危險時，會延遲來自個別使用者的要求超出臨界值。 當共享資源接近不堪重負時，此限制僅著重於避免中斷。 個別使用者通常只會在發生下列其中一個事件時收到延遲的要求：
- 其中一個共享資源有被壓倒的風險
- 其個人使用量超過一般使用者在五分鐘的時段內耗用量的 200 倍
延遲量取決於用戶的持續耗用量層級。 延遲範圍從每個要求幾毫秒到30秒。 一旦耗用量移至零，或資源不再不堪重負，延遲就會在五分鐘內停止。 如果耗用量仍然很高，延遲可能會無限期地繼續保護資源。
當使用者要求延遲大量時，該使用者就會在 Web 中收到電子郵件和警告橫幅。 對於建置服務帳戶和沒有電子郵件位址的其他人，Project Collection 管理員 istrators 群組的成員會取得電子郵件。 如需詳細資訊，請參閱使用量監視。
當個別使用者的要求遭到封鎖時，收到 HTTP 代碼 429 的回應（要求太多），訊息類似下列訊息：
TF400733: The request has been canceled: Request was blocked due to exceeding usage of resource <resource name> in namespace <namespace ID>.
Azure DevOps 輸送量單位 （TSTU）
Azure DevOps 用戶會耗用許多共用資源，而耗用量取決於下列因素：
- 將大量檔案上傳至版本控制，會在資料庫和記憶體帳戶上建立大量負載
- 複雜的工作專案追蹤查詢會根據他們搜尋的工作項目數目來建立資料庫負載
- 從版本控制下載檔案以建置磁碟驅動器負載，產生記錄輸出
- 所有作業都會在服務的各個部分耗用CPU和記憶體
為了容納，Azure DevOps 資源耗用量是以稱為 Azure DevOps 輸送量單位或 TSTU 的抽象單位表示。 TSTU 最終會納入下列專案的混合：
- Azure SQL 資料庫 DTU 作為資料庫耗用量的量值
- 應用層和作業代理程式 CPU、記憶體和 I/O 作為計算耗用量的量值
- Azure 儲存體 頻寬作為記憶體耗用量的量值
目前，TSTU 主要著重於 Azure SQL 資料庫 DTU，因為 Azure SQL 資料庫 是最常因過度耗用量而不知所措的共享資源。 單一 TSTU 是我們預期 Azure DevOps 單一一般使用者每五分鐘產生一般負載的平均負載。 一般使用者也會產生負載尖峰。 這些尖峰通常是每五分鐘 10 個或更少的 TSTU。 頻率較低，尖峰高達 100 個 TSTU。
全域耗用量限制是 200 個 TSTU 在滑動五分鐘的時段內。
我們建議您至少響應 Retry-After 標頭。 如果您在任何回應中偵測 Retry-After 到標頭，請等到一段時間過後再傳送另一個要求。 這麼做可協助用戶端應用程式體驗較少的強制延遲。 請記住，回應為 200，因此您不需要將重試邏輯套用至要求。
可能的話，建議您進一步監視 X-RateLimit-Remaining 和 X-RateLimit-Limit 標頭。 這麼做可讓您大致瞭解接近延遲閾值的速度。 您的用戶端可以智慧地回應並分散其要求一段時間。
注意
工具和應用程式用來與 Azure DevOps 整合的身分識別，可能需要比允許的使用量限制不時更高的速率和使用量限制。 您可以將基本 + 測試計劃存取層級指派給應用程式所使用的必要身分識別，以提高額外的速率和使用量限制。 完成較高的速率限制需求之後，您可以回到身分識別之前具有的存取層級。 您只需支付基本 + 測試計劃存取層級的費用，才會在指派給身分識別的時間。
已指派 Visual Studio Enterprise 訂用帳戶的身分識別，在移除之前，無法指派 基本 + 測試方案 存取層級。
管線
Azure Pipelines 的速率限制很類似。 每個管線都會被視為追蹤其本身資源耗用量的個別實體。 即使組建代理程式是自我裝載的，它們仍會以複製和傳送記錄的形式產生負載。
我們會在滑動 5 分鐘視窗中，為個別管線套用 200 個 TSTU 限制。 此限制與使用者的全域耗用量限制相同。 如果管線因速率限制而延遲或封鎖，則附加記錄中會出現訊息。
API 用戶端體驗
當要求延遲或封鎖時，Azure DevOps 會傳回回應標頭，以協助 API 用戶端做出回應。 雖然未完全標準化，但這些標頭 與其他熱門服務大致一致。
下表列出可用的標頭及其意義。
X-RateLimit-Delay除了 之外，所有這些標頭都會在要求開始延遲之前傳送。
此設計可讓客戶端主動降低要求速率的機會。
標頭名稱
說明
Retry-After
傳送的 RFC 6585 指定標頭會告訴您在傳送下一個要求之前要等待多久的時間，才會落在偵測閾值之下。 單位：秒。
X-RateLimit-Resource
自定義標頭，指出已達到的服務與臨界值類型。 臨界值類型和服務名稱可能會隨著時間而有所不同，而且沒有警告。 我們建議將此字串顯示給人類，但不依賴該字串進行計算。
X-RateLimit-Delay
要求延遲的時間長度。 單位：最多三個小數位數的秒數（毫秒）。
X-RateLimit-Limit
在實施延遲之前允許的 TSTU 總數。
X-RateLimit-Remaining
延遲之前剩餘的 TSTU 數目。 如果要求已延遲或遭到封鎖，則為 0。
X-RateLimit-Reset
屆時，如果所有資源耗用量立即停止，追蹤的使用量會傳回 0 個 TSTU。 以 Unix epoch 時間表示。
工作追蹤、程序及專案限制
Azure DevOps 會限制您在組織中可以擁有的項目數目，以及您可以在每個項目中擁有的小組數目。 也請注意工作項目、查詢、待辦專案、面板、儀錶板等等的限制。 如需詳細資訊，請參閱 工作追蹤、程序和專案限制。
Wiki
除了一般 存放庫限制之外，針對項目定義的wiki限制為每一個檔案 25 MB。
服務連線
建立服務連線時沒有每個專案的限制。 不過，可能會有一些限制，這些限制是透過 Microsoft Entra ID 來強加的。 如需詳細資訊，請檢閱下列文章：