通过

费率和使用限制

Azure DevOps Services

Azure DevOps Services 使用多租户来降低成本并提高性能。 当共享资源的其他用户消耗量激增时，此设计可能会导致性能问题或中断。 为了帮助防止这种情况，Azure DevOps 会限制每个用户可以使用的资源，以及他们可以向某些命令发出的请求数。 如果超出这些限制，可能会延迟或阻止将来的请求。

在 Git 限制 和 避免达到速率限制的最佳实践中了解详细信息。

全局消耗限制

Azure DevOps 具有全局消耗限制，当共享资源面临不堪重负的风险时，会延迟单个用户发出的请求。 当共享资源即将不堪重负时，此限制有助于避免中断。 单个用户通常仅在发生以下事件之一时遇到延迟的请求：

  • 其中一个共享资源面临超负荷的风险。
  • 在任一滑动的五分钟窗口中，他们的个人使用情况超过典型用户的使用量的200倍。

延迟取决于用户的持续消耗级别。 延迟范围从每个请求的毫秒到 30 秒不等。 当消耗量下降到零或资源不堪重负时，延迟在五分钟内停止。 如果消耗量较高，延迟可能会无限期地持续，以保护资源。

当用户请求被大量延迟时，用户会收到一封电子邮件和 Web 中的警告横幅。 对于没有电子邮件地址的构建服务帐户和其他帐户，项目集合管理员组的成员将收到该电子邮件。 有关详细信息，请参阅使用情况监视。

当单个用户的请求被阻止时，用户会收到 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 用户在五分钟内生成的平均负载。
  • 普通用户活动每 5 分钟可以生成不超过 10 个 TSTU 的峰值。
  • 最大但频率较低的峰值最多可以达到 100 个 TSTU。
  • 全局限制在任何滑动的五分钟窗口中为 200 个 TSTU。

最佳做法

  • 如果在响应中收到 Retry-After 标头，请遵守在发送另一个请求之前等待指定的时间。 响应仍返回 HTTP 200，因此不需要重试逻辑。
  • 监视 X-RateLimit 头信息：如果可用，跟踪 X-RateLimit-Remaining 和 X-RateLimit-Limit，以大致了解您接近阈值的速度。 这样，客户端就可以顺利处理请求突发，并避免强制延迟。

注释

用于与 Azure DevOps 集成的工具和应用程序使用的标识偶尔需要更高的速率和使用量限制，超出允许的消耗限制。 通过将 基本 + 测试计划 访问级别分配给应用程序使用的标识来增加这些限制。 不再需要更高的速率限制后，请还原到以前的访问级别。 只有在分配给身份的持续时间内，才对 基本 + 测试计划 访问级别收费。 在删除订阅之前，无法为已分配 Visual Studio Enterprise 订阅的标识分配 基本 + 测试计划 访问级别。

Pipelines

速率限制的工作方式与 Azure Pipelines 的工作方式相同。 每个管道都是单个实体，并单独跟踪其资源消耗量。 即使生成代理是自承载的，它们也会通过克隆和发送日志来生成负载。

滑动 5 分钟窗口中每个管道的 TSTU 限制为 200 个。 此限制与用户的全局消耗限制匹配。 如果速率限制导致管道延迟或阻塞，您会在附加的日志中收到一条消息。

API 客户端体验

当请求延迟或阻止时，Azure DevOps 将返回响应标头以帮助 API 客户端做出响应。 虽然未完全标准化，但这些标头 与其他常用服务大致一致。

下表列出了可用的标头及其含义。 除了X-RateLimit-Delay以外，所有这些标头都是在请求开始延迟之前发送的。 此设计可让客户端主动降低其请求速率。

标头名称

说明

“重试 - 显示已达到服务和阈值类型的自定义标头。 阈值类型和服务名称可能会随时间而变化，且不会显示警告。 将此字符串显示给人类，但不依赖它进行计算。

X-RateLimit-Delay

请求延迟的时间是多久。 单位：最多包含三个小数位数（毫秒） 的秒数。

X-RateLimit-Limit

在强制延迟之前允许的 TSTU 总数。

X-RateLimit-Remaining

延迟开始前剩余的 TSTU 数量。 如果请求已延迟或被阻止，则为 0。

X-RateLimit-Reset

当所有资源消耗立即停止时，跟踪的使用情况将返回到 0 个 TSTU。 以 Unix 纪元时间表示。

工作跟踪、流程管理、& 项目限制

Azure DevOps 限制组织中可以拥有的项目数，以及每个项目中可以拥有的团队数。 工作项、查询、待办事项、看板、仪表板等也有限制。 有关详细信息，请参阅 工作跟踪、流程和项目限制。

维基

除了通常的 存储库限制外，项目中的 Wiki 文件最多可为 25 MB。

服务连接

创建服务连接时，对每个项目没有任何限制。 但是，可以通过Microsoft Entra ID 施加限制。 如需了解更多信息，请参阅以下文章：

相关内容