Поделиться через

Ограничения скорости и использования

  • Статья

Azure DevOps Services

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 используют множество общих ресурсов, а потребление зависит от следующих факторов:

  • Отправка большого количества файлов в управление версиями создает большую нагрузку на базы данных и учетные записи хранения.
  • Сложные запросы отслеживания рабочих элементов создают нагрузку на базу данных в зависимости от количества рабочих элементов, которые они обрабатывают.
  • Скачивая файлы из системы управления версиями, генерирует загрузку диска и создаёт журналы.
  • Все операции используют ЦП и память в различных частях службы.

Для адаптации потребление ресурсов Azure DevOps выражается в абстрактных единицах, называемых единицами пропускной способности Azure DevOps (TSTUs). ТСОП в конечном итоге включают в себя сочетание следующих элементов:

  • DTU для базы данных Azure SQL как мера потребления баз данных
  • Уровень приложений и агент заданий ЦП, память и операции ввода-вывода в качестве меры потребления вычислительных ресурсов
  • Пропускная способность службы хранилища Azure в качестве меры потребления хранилища

На данный момент TSTUs сосредоточены главным образом на DTU для баз данных SQL Azure, так как базы данных SQL Azure являются общими ресурсами, которые чаще всего перегружаются из-за чрезмерного потребления. Один TSTU — это средняя нагрузка, ожидаемая, что типичный пользователь Azure DevOps будет генерировать в течение пяти минут. Типичные пользователи также создают пики нагрузки. Эти пики обычно составляют 10 или менее единиц TSTU в течение пяти минут. Реже пики идут до 100 ТСОП.

Глобальный лимит потребления составляет 200 ТСОП в пределах скользящего пятиминутного окна.

Мы рекомендуем хотя бы ответить на заголовок Retry-After. Если вы обнаружите заголовок Retry-After в любом ответе, подождите, пока не пройдет некоторое время, прежде чем отправить другой запрос. Это помогает клиентскому приложению столкнуться с меньшим количеством принудительных задержек. Помните, что ответ равен 200, поэтому вам не нужно применять логику повторных попыток к запросу.

По возможности мы рекомендуем отслеживать заголовки X-RateLimit-Remaining и X-RateLimit-Limit. Это позволяет приблизительно определить, насколько быстро вы приближаетесь к пороговой задержке. Клиент может интеллектуально реагировать и распространять свои запросы с течением времени.

Примечание.

Удостоверения, используемые средствами и приложениями для интеграции с Azure DevOps, могут иногда потребовать более высоких скоростей и ограничений использования за пределы допустимого потребления. Вы можете увеличить эти ограничения, назначив уровень доступа Basic + Test Plans нужным удостоверениям, используемым вашим приложением. После выполнения необходимых более высоких ограничений скорости можно вернуться к предыдущему уровню доступа. Плата взимается за базовый уровень доступа и планы тестирования только на период, назначенный удостоверению.

Удостоверения, уже назначенные на подписку Visual Studio Enterprise, не могут быть назначены на уровень доступа Basic + Test Plans, пока они не будут сняты.

Трубопроводы

Ограничение скорости аналогично в Azure Pipelines. Каждый конвейер обрабатывается как отдельная сущность с отслеживанием потребления ресурсов. Даже если агенты сборки размещённые самостоятельно, они создают нагрузку в виде клонирования и отправки журналов.

Мы применяем ограничение 200 TSTU для отдельного конвейера в скользящем 5-минутном окне. Это ограничение совпадает с глобальным ограничением потребления для пользователей. Если конвейер задерживается или блокируется ограничением скорости, сообщение появляется в вложенных журналах.

Взаимодействие с клиентом API

Когда запросы будут отложены или заблокированы, Azure DevOps возвращает заголовки ответов, чтобы помочь клиентам API реагировать. Хотя эти заголовки не полностью стандартизированы, эти заголовки широко соответствуют другим популярным службам.

В следующей таблице перечислены доступные заголовки и то, что они означают. За исключением X-RateLimit-Delay, все эти заголовки отправляются, прежде чем запросы начинают получать задержки. Эта конструкция дает клиентам возможность заранее замедлить их скорость запросов.

название заголовка

Описание

Retry-After

Заголовок RFC 6585указывает, сколько времени следует подождать, прежде чем отправлять следующий запрос, чтобы не превысить порог обнаружения. Единицы: секунды.

X-RateLimit-Resource

Пользовательский заголовок, указывающий на службу и тип порогового значения, достигнутого. Типы пороговых значений и имена служб могут меняться со временем и без предупреждения. Мы рекомендуем отобразить эту строку для человека, но не полагаться на нее для вычислений.

X-RateLimit-Delay

Сколько времени запрос был отложен. Единицы: секунды с числом десятичных разрядов до трёх (например, миллисекунды).

X-RateLimit-Limit

Общее количество ТСТУ, разрешенных до введения задержек.

X-RateLimit-Remaining

Количество оставшихся TSTUs до наступления задержки. Если запросы уже задерживаются или блокируются, это 0.

X-RateLimit-Reset

Время, к которому, при немедленном остановке потребления ресурсов, отслеживаемое использование вернется к 0 ТСОП. Выражено во времени эпохи Unix.

Ограничения для отслеживания хода выполнения работы, процесса и проекта

Azure DevOps накладывает ограничения на количество проектов, которые можно использовать в организации, и количество команд, которые можно использовать в каждом проекте. Кроме того, следует учитывать ограничения для рабочих элементов, запросов, невыполненных работ, досок, панелей мониторинга и т. д. Дополнительные сведения см. в разделе Ограничения для отслеживания хода выполнения работы, процесса и проекта.

Вики

Помимо обычных ограничений репозитория, вики-сайты, определенные для проекта, ограничены 25 МБ в один файл.

Подключения к сервису

Ограничения для каждого проекта отсутствуют при создании подключений к службе. Однако могут быть ограничения, которые накладываются с помощью идентификатора Microsoft Entra. Дополнительные сведения см. в следующих статьях: