Как избежать регулирования количества запросов или блокировки в 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, чтобы обеспечить минимальную задержку до удаления регулирования. Заголовки RateLimit HTTP отправляют вам ранние сигналы, когда вы приближаетесь к ограничениям, и вы можете упреждающе уменьшать запросы, чтобы избежать нажатия на регулирование.

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

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

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

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

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

Заголовок 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 указывает количество секунд до восстановления квоты.

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

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

  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 со следующим соглашением об именовании.

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

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

1. Подумайте, необходимы ли эти запросы для вашего приложения. Например, если вы используете пользовательский поисковый сайт, который выполняет множество одновременных запросов, проверка, можно ли удалить некоторые из этих запросов, не влияя на возможности поиска в вашей организации. Кроме того, можно попробовать современный поиск людей в Поиске (Майкрософт), выполнив поиск на начальной странице SharePoint. Поиск людей в Поиске (Майкрософт) был оптимизирован для повышения производительности и более релевантных результатов.
2. Избегайте одновременных запросов. Например, вместо того, чтобы отправлять 10 запросов одновременно, выполняйте их последовательно, а затем выполните следующий запрос только после завершения предыдущего запроса. Вам может потребоваться кэшировать эти результаты, если они вам нужны быстро, например при загрузке страницы.
3. Попробуйте объединить запросы в один запрос. Например, вместо 10 одновременных запросов для WorkEmail:[email protected], WorkEmail:[email protected],..., WorkEmail:[email protected]попробуйте один запрос , WorkEmail:[email protected] WorkEmail:[email protected] ... WorkEmail:[email protected].
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
• Четыре варианта аналитики сайта