Ограничения скорости и использования
Azure DevOps Services
Azure DevOps Services использует многотенантность для снижения затрат и повышения производительности. Эта конструкция оставляет пользователей уязвимыми к проблемам производительности и даже сбоям, когда другие пользователи общих ресурсов имеют пики потребления. Таким образом, Azure DevOps ограничивает использование ресурсов, а также количество запросов, которые они могут выполнять для определенных команд. При превышении этих ограничений будущие запросы могут быть отложены или заблокированы.
Дополнительные сведения см. в ограничениях Git и рекомендациях, чтобы избежать ограничения скорости попадания.
Глобальный предел потребления
В настоящее время Azure DevOps имеет глобальный предел потребления, который задерживает запросы от отдельных пользователей за пороговое значение, когда общие ресурсы находятся в опасности перегружены. Это ограничение сосредоточено исключительно на том, чтобы избежать сбоев, когда общие ресурсы близки к перегрузке. Отдельные пользователи обычно получают отложенные запросы только при возникновении одного из следующих инцидентов:
- Один из общих ресурсов подвержен риску перегрузки
- Их личное использование превышает 200 раз потребление типичного пользователя в течение пяти минут
Сумма задержки зависит от устойчивого уровня потребления пользователем. Задержки варьируются от нескольких миллисекунд на запрос до 30 секунд. После того как потребление переходит к нулю или ресурс больше не перегружен, задержки останавливаются в течение пяти минут. Если потребление остается высоким, задержки могут продолжаться неограниченное время для защиты ресурса.
Когда запрос пользователя задерживается на значительную сумму, пользователь получает сообщение электронной почты и баннер предупреждения в Интернете. Для учетной записи службы сборки и других пользователей без адреса электронной почты участники группы "Коллекция проектов" Администратор 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 (TSTUs)
Пользователи Azure DevOps используют множество общих ресурсов, а потребление зависит от следующих факторов:
- Отправка большого количества файлов в управление версиями создает большую нагрузку на базы данных и учетные записи хранения.
- Сложные запросы отслеживания рабочих элементов создают нагрузку базы данных на основе количества рабочих элементов, которые они ищут через
- Создает загрузку диска, скачивая файлы из системы управления версиями, создавая выходные данные журнала
- Все операции используют ЦП и память в различных частях службы.
Для размещения потребление ресурсов Azure DevOps выражается в абстрактных единицах пропускной способности Azure DevOps или TSTUs. ТСОП в конечном итоге включают в себя сочетание следующих элементов:
- База данных SQL Azure DTU в качестве меры потребления базы данных
- Уровень приложений и агент заданий ЦП, память и операции ввода-вывода в качестве меры потребления вычислительных ресурсов
- служба хранилища Azure пропускную способность в качестве меры потребления хранилища
Сейчас ТСОП в основном ориентированы на База данных SQL Azure единиц DTU, так как База данных SQL Azure являются общими ресурсами, наиболее часто перегруженными чрезмерным потреблением. Один TSTU — это средняя нагрузка, ожидаемая, что один обычный пользователь Azure DevOps будет генерировать в течение пяти минут. Обычные пользователи также создают пики нагрузки. Эти пики обычно составляют 10 или меньше ТСОП в течение пяти минут. Реже пики идут до 100 ТСОП.
Глобальный предел потребления составляет 200 ТСОП в скользящем пятиминутном окне.
Рекомендуется по крайней Retry-After мере ответить на заголовок. Если вы обнаружите заголовок в любом ответе Retry-After , подождите, пока не пройдет некоторое время, прежде чем отправлять другой запрос. Это помогает клиентскому приложению столкнуться с меньшим количеством принудительных задержек. Помните, что ответ равен 200, поэтому вам не нужно применять логику повторных попыток к запросу.
По возможности рекомендуется отслеживать X-RateLimit-Remaining и X-RateLimit-Limit заголовки. Это позволяет приблизительно определить, насколько быстро вы приближаетесь к пороговой задержке. Клиент может интеллектуально реагировать и распространять свои запросы с течением времени.
Примечание.
Удостоверения, используемые средствами и приложениями для интеграции с Azure DevOps, могут потребовать более высоких скоростей и ограничений использования за пределы допустимого ограничения потребления от времени. Вы можете получить дополнительные ограничения скорости и использования, назначив уровень доступа Basic + Test Plans требуемым удостоверениям, используемым приложением. После повышения ограничений на скорость можно вернуться к уровню доступа, который использовался удостоверением. Плата за стоимость уровня доступа "Базовый и тестовые планы " взимается только за то время, когда оно назначено удостоверению.
Удостоверения, которые уже назначены подписке Visual Studio Enterprise, нельзя назначить уровень доступа "Базовый" и "Тестовые планы ", пока они не будут удалены.
Конвейеры
Ограничение скорости аналогично azure Pipelines. Каждый конвейер обрабатывается как отдельная сущность с отслеживанием потребления ресурсов. Даже если агенты сборки размещаются самостоятельно, они создают нагрузку в виде клонирования и отправки журналов.
Мы применяем ограничение в 200 TSTU для отдельного конвейера в скользящем 5-минутном окне. Это ограничение совпадает с глобальным ограничением потребления для пользователей. Если конвейер задерживается или блокируется ограничением скорости, сообщение появляется в вложенных журналах.
Взаимодействие с клиентом API
Когда запросы будут отложены или заблокированы, Azure DevOps возвращает заголовки ответов, чтобы помочь клиентам API реагировать. Хотя эти заголовки не полностью стандартизированы, эти заголовки широко соответствуют другим популярным службам.
В следующей таблице перечислены доступные заголовки и то, что они означают.
X-RateLimit-DelayКроме того, все эти заголовки отправляются, прежде чем запросы начинают получать задержки.
Эта конструкция дает клиентам возможность заранее замедлить их скорость запросов.
Имя заголовка
Description
Retry-After
Заголовок RFC 6585, отправленный, чтобы узнать, сколько времени ждать, прежде чем отправлять следующий запрос, подпадает под пороговое значение обнаружения. Единицы: секунды.
X-RateLimit-Resource
Пользовательский заголовок, указывающий на службу и тип порогового значения, достигнутого. Типы пороговых значений и имена служб могут меняться со временем и без предупреждения. Мы рекомендуем отобразить эту строку для человека, но не полагаться на нее для вычислений.
X-RateLimit-Delay
Сколько времени запрос был отложен. Единицы: секунды с тремя десятичными разрядами (миллисекундами).
X-RateLimit-Limit
Общее количество разрешенных ТСОП до введения задержек.
X-RateLimit-Remaining
Количество оставшихся ТСОП до задержки. Если запросы уже задерживаются или блокируются, это 0.
X-RateLimit-Reset
Время, в котором, если все потребление ресурсов остановлено немедленно, отслеживаемое использование возвращается к 0 ТСОП. Выражено в эпоху Unix.
Ограничения для отслеживания хода выполнения работы, процесса и проекта
Azure DevOps накладывает ограничения на количество проектов, которые можно использовать в организации, и количество команд, которые можно использовать в каждом проекте. Кроме того, следует учитывать ограничения для рабочих элементов, запросов, невыполненных работ, досок, панелей мониторинга и т. д. Дополнительные сведения см. в разделе "Отслеживание работы", "Процесс" и "Ограничения проекта".
Вики
Помимо обычных ограничений репозитория, вики-сайты, определенные для проекта, ограничены 25 МБ на один файл.
Подключения к службе
Ограничения для каждого проекта отсутствуют при создании подключений к службе. Однако могут быть ограничения, которые накладываются с помощью идентификатора Microsoft Entra. Дополнительные сведения см. в следующих статьях: