费率和使用限制

  • 项目

Azure DevOps Services

Azure DevOps Services 使用多租户来降低成本并提高性能。 此设计使用户容易受到性能问题的影响，甚至当共享资源的其他用户的消耗量激增时，甚至中断。 因此，Azure DevOps 会限制个人可以使用的资源，以及他们可以对某些命令发出的请求量。 超出这些限制后，可能会延迟或阻止将来的请求。

有关详细信息，请参阅 Git 限制 和 最佳做法，以避免达到速率限制。

全局消耗限制

Azure DevOps 目前具有全局消耗限制，当共享资源处于不堪重负的危险时，会延迟来自单个用户的请求超出阈值。 当共享资源即将不堪重负时，此限制专门侧重于避免中断。 单个用户通常仅在发生以下事件之一时收到延迟的请求：

  • 其中一个共享资源面临不知所措的风险
  • 他们的个人使用情况超过典型用户在（滑动）5 分钟时段内消耗的 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 的单个普通用户每 5 分钟生成的平均负载。 普通用户还会在负载中生成峰值。 这些峰值通常是每 5 分钟 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 个 TTU。 以 Unix 纪元时间表示。

工作跟踪、流程和项目限制

Azure DevOps 对组织中可以拥有的项目数以及每个项目中可以拥有的团队数施加限制。 另请注意工作项、查询、积压工作、板、仪表板等的限制。 有关详细信息，请参阅 工作跟踪、流程和项目限制。

Wiki

除了通常 的存储库限制外，为每个项目定义的 Wiki 限制为每个文件 25 MB。

服务连接

创建服务连接没有针对每个项目的限制。 但是，可能存在通过 Microsoft Entra ID 施加的限制。 有关更多信息，请查看以下文章：