速率和使用量限制
Azure DevOps Services
Azure DevOps Services 使用多租戶來降低成本並改善效能。 此設計容易讓使用者面臨效能問題，甚至在其共用資源的其他使用者耗用量激增時，亦可能導致中斷。 因此，Azure DevOps 會限制個人可以取用的資源，以及他們可以對特定命令提出的要求數量。 超過這些限制時，未來要求可能會延遲或封鎖。
如需詳細資訊，請參閱 Git 限制 和 最佳做法，以避免達到速率限制。
全域耗用量限制
Azure DevOps 目前具有全域耗用量限制，當共用資源處於不堪重負的危險時，會延遲來自個別使用者的要求超出臨界值。 當共享資源接近不堪重負時，此限制僅著重於避免中斷。 個別使用者通常只會在發生下列其中一個事件時收到延遲的要求：
- 其中一個共享資源有被壓倒的風險
- 其個人使用量超過典型使用者在任意連續五分鐘內耗用量的 200 倍
延遲量取決於用戶的持續耗用量層級。 延遲範圍從每次請求幾毫秒到 30 秒。 一旦耗用量移至零，或資源不再不堪重負，延遲就會在五分鐘內停止。 如果耗用量持續處於高位，為了保護資源，延遲可能會無限期地繼續。
當使用者的請求延遲相當長的時間時，該使用者會收到一封電子郵件並且在網頁上看到警告橫幅。 對於建立服務帳戶以及其他沒有電子郵件地址的帳戶，Project Collection Administrators 群組的成員會收到電子郵件。 如需詳細資訊，請參閱使用量監視。
當個別使用者的要求遭到封鎖時，收到 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 輸送量單位
Azure DevOps 用戶會耗用許多共用資源，而耗用量取決於下列因素：
- 將大量檔案上傳至版本控制，會在資料庫和記憶體帳戶上建立大量負載
- 複雜的工作專案追蹤查詢會根據他們搜尋的工作項目數目來造成資料庫負載。
- 從版本控制下載檔案以建置磁碟驅動器負載，產生記錄輸出
- 所有作業都會在服務的各個部分耗用CPU和記憶體
為了容納，Azure DevOps 資源耗用量是以稱為 Azure DevOps 輸送量單位（TTU）的抽象單位表示。 TSTU 最終會納入以下項目的混合：
- Azure SQL Database DTUs 作為一種資料庫耗用量的量值
- 應用層級和作業代理程式的 CPU、記憶體和 I/O 作為計算資源消耗的衡量標準。
- Azure 記憶體頻寬作為記憶體耗用量的量值
目前，TSTU 主要專注於 Azure SQL Database DTU，因為 Azure SQL Database 是最常因過度使用而資源枯竭的共享資源。 單一 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限制為每一個檔案 25 MB。
服務連線
建立服務連線時沒有每個專案的限制。 不過，可能會有限制，這些限制是透過Microsoft Entra ID 來強加。 如需詳細資訊，請檢閱下列文章：