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

Как избежать регулирования количества запросов или блокировки в SharePoint Online

  • Статья

Узнайте о регулирования в SharePoint Online и ознакомьтесь с тем, как избежать регулирования или блокировки.

Не похоже на этом? Вы запускаете приложение, например для сканирования файлов в SharePoint Online, но применяется регулирование. Или еще хуже — к вам применяется блокировка. Что происходит и что можно сделать, чтобы сделать его остановить?

Что такое регулирование?

SharePoint Online использует регулирование для поддержания оптимальной производительности и надежности службы SharePoint Online. Регулирование ограничивает количество вызовов API или операций в течение периода времени, чтобы предотвратить чрезмерное использование ресурсов.

Что происходит при получения ограничением в SharePoint Online ?

Когда превышаются ограничения использования, SharePoint Online регулирует все последующие запросы от этого клиента в течение короткого периода времени.

Для запросов, которые выполняются пользователем прямо в браузере, SharePoint Online перенаправит пользователя на страницу с информацией о регулировании, а эти запросы не выполнятся.

Для запросов, выполняемых приложением, включая вызовы Microsoft Graph, CSOM или REST, SharePoint Online возвращает код состояния HTTP 429 ("Слишком много запросов") или 503 ("Сервер слишком занят"), и запросы завершатся ошибкой.

  • HTTP 429 указывает, что вызывающее приложение отправило слишком много запросов за период времени и превысило предопределенный предел.
  • HTTP 503 указывает, что служба не готова к обработке запроса. Распространенная причина заключается в том, что служба испытывает больше временных пиков нагрузки, чем ожидалось.

В обоих случаях в отклик включается заголовок Retry-After, в котором указывается, сколько вызывающее приложение должно подождать перед повторным или новым запросом. Регулируемые запросы учитываются в ограничениях на использование, поэтому несоблюдение Retry-After может привести к дополнительному регулированию.

Если проблемный процесс по-прежнему превышает ограничения использования, SharePoint Online может полностью блокировать приложение или определенные шаблоны запросов от приложения. В этом случае приложение продолжит получать код состояния HTTP 503, а Майкрософт уведомит клиент о блокировке в Центре сообщений Office 365.

Регулирование пользователей

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

При этом пользователь редко подвергается регулированию в SharePoint Online. Эта служба надежна и рассчитана на работу с большими объемами. Если вы подверглись регулированию, в 99 % случаев это связано с нестандартным кодом, например с настраиваемыми веб-частями, сложным представлением списка и запросами или с настраиваемыми приложениями, которые запускают пользователи. Это не означает, что не существует других причин подвергнуться регулированию, но они встречаются реже. Например, один пользователь, синхронизирующий большой объем данных на 10 компьютерах одновременно, может активировать регулирование.

Регулирование приложений

Помимо регулирования по учетным записям пользователей ограничения также применяются к приложениям в клиенте.

Каждое приложение использует собственные ограничения в клиенте, которые основаны на количестве приобретенных лицензий на организацию (включенные лицензии см. в планах, перечисленных в разделе Ограничения SharePoint). Каждый запрос, который приложение выполняет во всех конечных точках API, включая Microsoft Graph, CSOM и REST, учитывается при использовании приложения.

SharePoint предоставляет различные API. Разным API соответствуют разные затраты в зависимости от сложности API. Затраты API нормализуются в SharePoint и выражаются единицами ресурсов. Ограничения приложения также определяются с помощью единиц ресурсов.

В таблице ниже определены ограничения единиц ресурсов для приложения в клиенте.

Количество лицензий 0–1 тыс. 1–5 тыс. 5–15 тыс. 15–50 тыс. 50 тыс. и более
Приложение за 1 минуту 1 200 2 400 3 600 4 800 6 000
Приложение ежедневно 1 200 000 2 400 000 3 600 000 4 800 000 6 000 000

Примечание.

Корпорация Майкрософт оставляет за собой право изменять ограничения на единицу ресурсов.

Для мультитенантных приложений:

  1. Каждый клиент, в котором размещается приложение, считается отдельным и работает независимо от других клиентов. Следовательно, для каждого приложения применяются собственные ограничения использования в каждом клиенте, как определено выше.
  2. Потребление единиц ресурсов приложением должно измеряться по каждому клиенту или приложению. Это гарантирует, что каждая пара "клиент—приложение" остается в пределах допустимых ограничений ресурсов, указанных для конкретного клиента.
  3. Если приложение достигнет предела ресурсов в пределах одного клиента, это событие не повлияет на другие экземпляры приложения, работающие в разных клиентах. Использование ресурсов каждого клиента изолировано, что предотвращает влияние между арендаторами.

Что касается затрат на API, API Microsoft Graph имеют предопределенную стоимость единицы ресурса на запрос:

Единицы ресурсов на запрос Операции
1
  • Запрос с одним элементом, например получение элемента
  • Разностный запрос с маркером
  • Скачивание файла из элемента диска
    		•
    2
  • Запрос с несколькими элементами, например перечисление дочерних элементов, за исключением разностных запросов с маркером
  • Создание, обновление, удаление и отправка
    		•
    5
  • Все операции с ресурсами разрешений, включая $expand=permissions
    		•

    Примечание.

    Мы оставляем за собой право изменить стоимость единицы ресурса API.

    Разностное использование маркера — самый эффективный способ сканирования содержимого в SharePoint. Мы более подробно рассмотрим рекомендации по проверке приложений. Чтобы помочь приложениям, соблюдающим инструкции, мы снижаем стоимость единицы ресурса разностных запросов с маркером до 1 единицы ресурса, хотя это запрос с несколькими элементами. Разностный запрос без маркера считается запросом с несколькими элементами и стоит 2 единицы ресурсов на запрос.

    При пакетной обработке запросы в пакете оцениваются индивидуально по единицам ресурсов.

    CSOM и REST не имеют предопределенных затрат на единицу ресурсов, и они обычно потребляют больше единиц ресурсов, чем API Microsoft Graph для достижения той же функциональности. Помимо ограничений на единицу ресурсов, CSOM и REST также распространяются на другие внутренние ограничения ресурсов, поэтому, если приложения вызывают CSOM и REST, они могут испытывать больше регулирования, чем ограничения, описанные в этом документе. Мы настоятельно рекомендуем по возможности выбирать API Microsoft Graph вместо ИНТЕРФЕЙСов CSOM и REST API.

    Так как ограничения приложений находятся в единицах ресурсов, фактическая скорость запросов, например запросов в минуту, зависит от выбора API приложения и стоимости соответствующей единицы ресурса API. Как правило, для оценки частоты запросов берется в среднем 2 единицы ресурсов на запрос, а ограничения единиц ресурсов делятся на 2, чтобы получить оценочную частоту запросов.

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

    Как обрабатывать регулирование?

    Ниже приведен краткий обзор рекомендаций по обработке регулирования.

    • Уменьшите количество одновременных запросов
    • Избегайте пиков запросов
    • По возможности выбирайте API Microsoft Graph вместо CSOM и REST API
    • Используйте HTTP-заголовки Retry-After и RateLimit
    • Оформите трафик так, чтобы мы знали, кто вы (см. раздел подробных рекомендаций по оформлению трафика ниже)

    Как уже говорилось ранее, Microsoft Graph — это api,родившиеся в облаке, которые имеют последние улучшения и оптимизации. Как правило, Microsoft Graph потребляет меньше ресурсов, чем CSOM и REST для достижения той же функциональности. Таким образом, внедрение Microsoft Graph может повысить производительность приложения и уменьшить регулирование.

    В период регулирования запросов обязательно используйте заголовок HTTP Retry-After, чтобы максимально ускорить устранение регулирования. HTTP-заголовки RateLimit отправляют вам ранние сигналы, когда вы приближаетесь к ограничениям, и вы можете заранее сократить количество запросов, чтобы избежать регулирования.

    Заголовок Retry-after

    Когда к приложениям применяется регулирование, SharePoint Online возвращает HTTP-заголовок Retry-After в запросе, в котором указывается, сколько вызывающее приложение должно подождать перед повторным или новым запросом.

    Соблюдение HTTP-заголовка Retry-After — это самый быстрый способ решения проблемы с регулированием, так как SharePoint Online динамически определяет подходящее время для повторной попытки.

    Регулируемые запросы учитываются в ограничениях на использование, поэтому несоблюдение Retry-After может привести к дополнительному регулированию. Иными словами, агрессивные повторные попытки работают против вызова приложений, так как даже если вызовы завершаются ошибкой, они по-прежнему учитываются в ограничениях использования. Соблюдение HTTP-заголовка Retry-After обеспечит минимальную задержку и сократит расходование квоты в регулируемых запросах.

    Заголовки RateLimit — предварительная версия

    Помимо заголовка Retry-After в ответе на регулируемые запросы, SharePoint Online также возвращает заголовки IETF RateLimit для выбранных ограничений в определенных условиях, чтобы помочь приложениям управлять ограничением скорости. Приложениям рекомендуется использовать эти заголовки с целью избежать регулирования.

    • RateLimit-Limit содержит ограничение в текущем периоде времени.
    • RateLimit-Remaining указывает оставшуюся квоту в текущем периоде.
    • RateLimit-Reset указывает количество секунд до восстановления квоты.

    Примечание.

    В настоящее время эти заголовки доступны в бета-версии и могут быть изменены. На момент внедрения заголовков спецификация IETF находилась в состоянии черновика. Текущая реализация основана на черновике 03 спецификации IETF. Существует вероятность изменений, когда спецификация станет окончательной, и мы адаптируемся к этим изменениям в будущем.

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

    limit Условие значение ограничения Описание
    Единица ресурсов приложения за 1 минуту Использование >= 80 % от лимита Единица ресурса Если приложение потребляет 80 % или более от ограничения в 1 минуту приложения, возвращается ограничение, оставшееся и сброс.

    Ниже приведены некоторые примеры, которые помогут вам понять заголовки RateLimit.

    • Приложение использовало 90 % квоты единиц ресурсов (1080 из 1200), и его использование находится в пределах всех ограничений, которые к нему применяются. Запрос будет выполнен успешно, и будут возвращены заголовки RateLimit.
    HTTP/1.1 200 Ok
RateLimit-Limit: 1200
RateLimit-Remaining: 120
RateLimit-Reset: 5
    • Приложение использовало 100 % квоты единиц ресурсов, поэтому оно регулируется из-за этой политики. Запрос подвергается регулированию, и возвращаются заголовки RateLimit. Retry-After соответствует RateLimit-Reset.
    HTTP/1.1 429 Too Many Requests
Retry-After: 31
RateLimit-Limit: 1200
RateLimit-Remaining: 0
RateLimit-Reset: 31
    • Приложение использовало 90 % квоты единиц ресурсов, но его использование уже достигло других ограничений, которые заголовки RateLimit не поддерживают. В этом случае запрос подвергается регулированию, а заголовки RateLimit не возвращаются, чтобы избежать путаницы, хотя условие для возврата заголовков удовлетворяется.
    HTTP/1.1 429 Too Many Requests
Retry-After: 9

    Дополнительные сведения см. в статье Предотвращение регулирования в приложении с помощью заголовков RateLimit в SharePoint Online.

    Как украсить http-трафик?

    Хорошо оформленный трафик получит более высокий приоритет, чем трафик без надлежащего оформления.

    Что такое неоформленный трафик?

    • Трафик не оформлен, если в вызовах API к SharePoint Online нет AppID/AppTitle и строки агента пользователя. Строка User-Agent должна иметь определенный формат, как описано ниже.
    • Если вы разрабатываете веб-приложение, запускаемое в браузере, вам не нужно выполнять эту рекомендацию, так как большинство современных браузеров не разрешают перезаписывать строку агента пользователя.

    Что делать?

    • Если вы создали приложение, рекомендуется зарегистрировать и использовать AppID и AppTitle. Это максимально увеличит общую производительность и в случае возникновения проблем в будущем поможет их решить. Включите также сведения о строке агента пользователя, как определено на следующем шаге.

      Примечание.

      Подробные сведения см. в Документации к Microsoft identity, например информацию о создании приложения Azure AD на странице Быстрый запуск: Регистрация приложения с помощью платформы удостоверений Майкрософт.

    • Обязательно включите строку User-Agent в вызов API к SharePoint со следующим соглашением об именовании.

    Тип Агент пользователя Описание
    Приложение независимого поставщика программного обеспечения ISV|CompanyName|AppName/Version Определите как независимого поставщика программного обеспечения и включите название компании, имя приложения, разделенное символом канала, а затем добавьте номер версии, разделенный символом косой черты.
    Корпоративное приложение NONISV|CompanyName|AppName/Version Через вертикальную черту укажите NONISV, название компании, название приложения, а затем через косую черту добавьте номер версии
    • Если вы создаете собственные библиотеки JavaScript, которые используются для вызова API SharePoint Online, убедитесь, что вы включили User-Agent сведения в HTTP-запрос и, возможно, зарегистрируйте веб-приложение в качестве приложения, если это подходит.

    Примечание.

    Формат строки агента пользователя должен соответствовать RFC2616, поэтому следуйте приведенным выше рекомендациям по правильным разделителям. Кроме того, можно добавить существующую строку агента пользователя с запрошенными сведениями.

    Распространенные сценарии регулирования в SharePoint Online

    Самые распространенные причины регулирования в SharePoint Online пользователей являются клиентской объектной модели (CSOM) или представлений состояния (REST) кода, который выполняет слишком много действий слишком часто.

    • Случайный трафик

      Постоянная нагрузка или повторяющиеся сложные запросы к SharePoint Online должны быть оптимизированы для незначительного воздействия. Невыполнение рекомендаций для сканирующих приложений, которые массово обрабатывают файлы, скорее всего, приведут к регулированию. Эти приложения включают в себя механизмы синхронизации, поставщики резервных копий, индексаторы поиска, механизмы классификации, средства защиты от потери данных и любые другие средства, которые пытаются обсудить все данные и применить к ним изменения.

    • Много избыточных элементов трафика

      Один процесс значительно превышает ограничения регулирования, постоянно, в течение длительного периода.

      • Веб-службы используются для формирования средство для синхронизации свойств профиля пользователя. Средство обновляет свойства профиля пользователя на основе сведений из бизнес-системы отдела кадров (HR) (LOB). Средство выполняет вызовы в слишком высокая частота.
      • Вы запускаете в SharePoint Online скрипт нагрузочного тестирования, что вызывает регулирование. Нагрузочное тестирование в SharePoint Online запрещено.
      • Настроить сайта группы на SharePoint Online, например, путем добавления индикатор состояния на домашней странице. Этот индикатор состояния обновляет часто, которая приводит к слишком большого числа звонков в службу SharePoint Online страницы — это инициирующую регулирования.
      • Запуск клиента синхронизации OneDrive при одновременной работе приложений миграции или приложений, которые обходят сайты и отсылают данные, может привести к высокому объему запросов, что может инициировать регулирование запросов.

    • Неподдерживаемые варианты использования

      При неподдерживаемом использовании SharePoint Online может возникать регулирование. Примером неподдерживаемого варианта является использование SharePoint и OneDrive в качестве промежуточной службы между Microsoft 365 и другим репозиторием.

    • Создание нескольких AppID для одного приложения

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

    Ограничения для конкретного сценария

    При использовании проверки подлинности только для приложений с разрешением Sites.Read.All

    Если вы используете API поиска SharePoint Online с проверкой подлинности только для приложений и приложением с разрешением Sites.Read.All (или более сильным), приложение будет зарегистрировано с полными разрешениями, и ему разрешено запрашивать все содержимое SharePoint Online (включая частное содержимое OneDrive для бизнеса пользователя).

    Чтобы служба оставалась быстрой и надежной, запросы, использующие такое разрешение, подвергаются регулированию на уровне 25 запросами в секунду. Поисковый запрос вернет ответ HTTP 429. Ожидая восстановления после регулирования, необходимо приостановить все поисковые запросы, которые вы могли отправлять в службу, используя аналогичное разрешение только для приложений. Выполнение дополнительных вызовов при получении откликов регулирования увеличит время, необходимое вашему приложению, чтобы прекратить регулирование.

    При поиске с помощью делегированных разрешений пользователя

    Поиск с делегированными разрешениями пользователя происходит, когда приложение отправляет запрос на поиск с разрешениями вошедшего пользователя. Примеры делегированных запросов: поле поиска на странице SharePoint, веб-часть поиска или пользовательское приложение, внедренное на странице SharePoint, и рабочий процесс Power Automate, запрашивающий сведения об элементах.

    Чтобы обеспечить стабильность службы, служба будет регулировать делегированные запросы пользователей, которые превышают 10 запросов в секунду на пользователя. Это ограничение на пользователя объединяет все запросы из всех приложений. Если один пользователь отправляет более 10 поисковых запросов в секунду, возвращается http 429. Запрашивающее приложение должно дождаться времени ожидания, указанного в заголовке ответа, прежде чем отправлять последующие запросы. При проектировании приложений на основе поиска, страниц SharePoint и рабочих процессов разработчики должны убедиться, что страница и приложение не превышают 10 запросов в секунду в совокупности и обрабатывают 429 ответов регулирования. Дополнительные сведения и рекомендации по проектированию страниц и оптимизации поиска см. в разделах Оптимизация поисковых запросов на страницах современных сайтов SharePoint Online и Использование средства диагностики страниц для SharePoint Online.

    При поиске результатов поиска людей

    При поиске с помощью источника результатов, запрашивающего результаты пользователей, мы можем регулировать любые запросы, превышающие ограничение в 25 запросов в секунду для всей организации. Это ограничение применяется ко всем запросам CSOM и REST поиска SharePoint, использующим либо встроенный источник результатов "Результаты локальных пользователей", либо настраиваемый источник результатов поиска людей.

    Если у вас есть приложения или компоненты, которые вызывают регулирование запросов на поиск людей, рекомендуется:

    1. Подумайте, необходимы ли эти запросы для вашего приложения. Например, если вы используете пользовательский поисковый сайт, который выполняет множество одновременных запросов, проверьте, можно ли удалить некоторые из этих запросов без какого-либо существенного влияния на возможности поиска в вашей организации. Кроме того, можно попробовать современный поиск людей в Поиске (Майкрософт), выполнив поиск на начальной странице SharePoint. Поиск людей в Поиске (Майкрософт) был оптимизирован для повышения производительности и более релевантных результатов.
    2. Избегайте одновременных запросов. Например, вместо того, чтобы отправлять 10 запросов одновременно, выполняйте их последовательно, а затем выполните следующий запрос только после завершения предыдущего запроса. Вам может потребоваться кэшировать эти результаты, если они вам нужны быстро, например при загрузке страницы.
    3. Попробуйте объединить запросы в один запрос. Например, вместо 10 одновременных запросов для WorkEmail:user1@constoso.com, WorkEmail:user2@constoso.com,..., WorkEmail:user10@contoso.comпопробуйте один запрос , WorkEmail:user1@constoso.com WorkEmail:user2@constoso.com ... WorkEmail:user10@contoso.com.
    4. Рассмотрите возможность использования API Microsoft Graph, если сценарий с большим объемом запросов (более 25 запросов в секунду) действительно необходим.

    При доступе к сайтам OneDrive

    Когда клиент предпринимает чрезмерные попытки доступа ко многим семействам веб-сайтов OneDrive, которые не существуют, мы можем регулировать запросы с IP-адреса этого клиента. Клиент получит ответ HTTP 429 при доступе к любому семейству веб-сайтов OneDrive в течение периода регулирования.

    Что делать, если вас заблокировали в SharePoint Online?

    Блокировка — это самая крайняя форма регулирования. Мы редко блокируем клиент, если не обнаруживаем долгосрочный чрезмерный трафик, который может поставить под угрозу общую работоспособность службы SharePoint Online. Мы применяем блокировку, чтобы чрезмерный трафик не снижал производительность и надежность SharePoint Online. Блокировка (которая обычно применяется на уровне приложения или пользователя) предотвращает выполнение проблемного процесса до решения проблемы. Если ваша подписка заблокирована, для снятия блокировки вы должны принять меры по изменению проблемных процессов.

    Если мы заблокируем вашу подписку, вы получите уведомление о блокировке в Центре сообщений Office 365. Это сообщение описывает причину блокировки, предоставляет руководство по решению проблемных вопросов и информирует о том, к кому обратиться, чтобы снять блокировку.

    См. также