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

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

• Что такое регулирование количества запросов?
• Как обрабатывать регулирование?
• Общие сценарии регулирования в 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.

Пиковое и Off-Peak использование

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

Единицы ресурсов

Некоторые ограничения измеряются в затратах на API. API Microsoft Graph имеют заранее определенную стоимость единицы ресурса за запрос:

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

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

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

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

Некоторые ограничения регулирования применяются на уровне клиента, чтобы гарантировать, что операции в совокупности не используют чрезмерное использование ресурсов.

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

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

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

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

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

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

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

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

Другие ограничения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заголовки RateLimit

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

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

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

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

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

Что делать?

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

  Примечание.

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

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

• Если вы создаете собственные библиотеки JavaScript, которые используются для вызова API SharePoint Online, убедитесь, что вы включили User-Agent информацию в свой HTTP-запрос и, возможно, зарегистрируйте свое веб-приложение также в качестве приложения (если это возможно).

Распространенные сценарии регулирования в 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 запросов в секунду. Это ограничение применяется ко всем поисковым запросам SharePoint, CSOM и REST, использующим готовый источник результатов "Локальные результаты People" или настраиваемый источник результатов поиска "Люди".

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

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

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

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

Клиенты с несколькими регионами и регулирование

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

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

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

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

См. также

• Приоритизация служб в SharePoint
• Диагностика проблем производительности в SharePoint Online
• Планирование и тестирование загрузки SharePoint Online
• Центр разработки с помощью Microsoft Graph
• Руководство по регулированию Microsoft Graph
• Предотвращение регулирования в приложении с помощью заголовков RateLimit в SharePoint Online
• Четыре варианта аналитики сайта