Azure DevOps 服務
Azure DevOps Services 使用多租戶來降低成本並改善效能。 當共用資源的其他使用者耗用量激增時，此設計可能會導致效能問題或中斷。 為了協助防止這種情況，Azure DevOps 會限制每個使用者可以取用的資源，以及他們可以對特定命令提出的要求數目。 如果您超過這些限制，未來的請求可能會延遲或封鎖。
在 Git 限制 和 避免達到速率限制的最佳做法中深入瞭解。
全域耗用量限制
Azure DevOps 具有全域取用限制，當共用資源面臨不堪重負的風險時，會延遲個別使用者的要求。 此限制有助於避免在共用資源接近不堪重負時發生中斷。 個別使用者通常只有在發生下列其中一個事件時才會遇到延遲的要求：
- 他們的共享資源之一面臨著不堪重負的風險。
- 他們的個人使用量在滑動的五分鐘窗口內超過了典型用戶消耗量的 200 倍。
延遲取決於使用者的持續消耗程度。 延遲範圍從每次請求幾毫秒到 30 秒。 當耗用量降至零或資源未不堪重負時，延遲會在五分鐘內停止。 如果消耗量居高不下，延遲可能會無限期地持續下去，以保護資源。
當使用者的請求遭遇顯著延遲時，使用者會收到一封電子郵件並在網頁上看到警告橫幅。 針對建置服務帳戶和其他沒有電子郵件地址的帳戶，專案集合系統管理員群組的成員會收到電子郵件。 如需詳細資訊，請參閱使用量監視。
當個別使用者的要求遭到封鎖時，使用者會收到 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 輸送量單位 （TSTU） 表示資源耗用量。 TSTU 是抽象的負載單位，代表不同資源的混合，包括：
- 資料庫使用量 - 主要透過 Azure SQL 資料庫 DTU 來測量。
- 運算使用量 — 來自應用程式層和工作代理程式的 CPU、記憶體和 I/O。
- 儲存體使用量 - Azure 儲存體頻寬。
備註
TSTU 是刻意設計得很抽象的。 它們彙總分散式基礎結構內運算、儲存和資料庫層的資源消耗。 基礎計量 （CPU、記憶體、I/O、DTU） 本身不會直接公開或有意義。 TSTU 提供統一的方式來表示負載，讓您更輕鬆地管理和監控使用情況，而不會暴露個別資源元件的全部複雜性。 您無法使用公式計算動作的 TSTU 使用量，但您可以在 使用量監視 頁面上查看作業耗用的 TSTU 數量。 某些作業，例如工作專案查詢，會隨著組織的成長和變更而改變耗用量，因此您可能需要定期進行基準測試，以保持準確。
目前，TSTU 主要著重於 Azure SQL 資料庫 DTU，因為資料庫是最有可能因過度耗用量而不堪重負的共用資源。
- 一個 TSTU 代表一般 Azure DevOps 使用者在五分鐘內產生的平均負載。
- 正常使用者的活動可能每五分鐘會產生 10 個 TSTU 或更少的峰值。
- 較大但頻率較低的尖峰最高可達 100 TSTU。
- 全域限制為每個滑動的五分鐘窗口內的200個TSTU。
最佳做法
- 請遵循 Retry-After 標頭：如果您在回應中收到此標頭，請等待指定的時間，然後再發送另一個請求。 回應仍會傳回 HTTP 200，因此不需要重試邏輯。
- 監控 X-RateLimit 標頭：如果可用，請追蹤
X-RateLimit-Remaining和X-RateLimit-Limit，以估算您接近閾值的速度。 這可讓您的用戶端平緩請求突發並避免被迫延遲。
備註
工具和應用程式用來與 Azure DevOps 整合的識別，有時可能需要高於允許取用限制的速率和使用量限制。 將 Basic + Test Plans 存取層級指派到應用程式使用的身分識別，以增加這些限制。 當您不再需要更高的速率限制後，請恢復到先前的存取層級。 您只需要在分配給身份的期間內支付 基本 + Test Plans 存取層級的費用。 在您移除 Visual Studio Enterprise 訂用帳戶之前，已指派訂用帳戶的身分識別無法指派至 [ 基本 + Test Plans ] 存取層級。
Pipelines
速率限制的運作方式與 Azure Pipelines 相同。 每個管線都是個別實體，其資源耗用量會個別追蹤。 即使建置代理程式是自我裝載的，它們也會透過複製和傳送日誌來產生負載。
在 200 分鐘的滑動窗口內，每個管道有 5 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 施加限制。 如需詳細資訊，請參閱下列文章：