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

  • Статья

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

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

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

для обеспечения оптимальной производительности и надежности службы SharePoint OnlineSharePoint 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

Примечание.

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

Что касается затрат на 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 и строки агента пользователя. Строка агента пользователя должна иметь указанный ниже формат.
    • Если вы разрабатываете веб-приложение, запускаемое в браузере, вам не нужно выполнять эту рекомендацию, так как большинство современных браузеров не разрешают перезаписывать строку агента пользователя.

    Что делать?

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

      Примечание.

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

    • Строка агента пользователя, включаемая в вызов API SharePoint, должна иметь следующий формат:

    Тип Агент пользователя Описание
    Приложение независимого поставщика программного обеспечения ISV|CompanyName|AppName/Version Через вертикальную черту укажите ISV, название компании и название приложения, а затем через косую черту добавьте номер версии
    Корпоративное приложение NONISV|CompanyName|AppName/Version Через вертикальную черту укажите NONISV, название компании, название приложения, а затем через косую черту добавьте номер версии
    • При создании собственных библиотек JavaScript, которые используются для вызова API SharePoint Online, не забудьте включить в свой 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. Ожидая восстановления после регулирования, необходимо приостановить все поисковые запросы, которые вы могли отправлять в службу, используя аналогичное разрешение только для приложений. Выполнение дополнительных вызовов при получении откликов регулирования увеличит время, необходимое вашему приложению, чтобы прекратить регулирование.

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

    При поиске с помощью источника результатов, запрашивающего результаты пользователей, мы можем регулировать любые запросы, превышающие ограничение в 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 запросов в секунду) действительно необходим.

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

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

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

    См. также