Общие сведения об ограничениях и шаблонах звонков

Применяется к: Для разработчиков

Эта статья позволит спланировать шаблоны звонков SharePoint Embedded перед созданием больших объемов операций с контейнерами и контентом. SharePoint Embedded выражает пропускную способность в единицах ресурсов в минуту (нормализованная модель запросов и затрат), а не как фиксированную частоту запросов в секунду; в разделе "Ограничения скорости API " объясняется, как преобразовать единицы ресурса в ожидаемую частоту запросов.

Лимиты, отмеченные меткой * , могут быть увеличены по запросу через службу поддержки Microsoft или через ваше контактное лицо по подключению SharePoint Embedded. Спланируйте ограничение по умолчанию и запросите его увеличение до того, как вы приблизитесь к нему в рабочей среде.

Ограничить категории

Ограничения SharePoint Embedded влияют:

  • Количество типов контейнеров*
  • Количество контейнеров*
  • Хранилище по типам контейнеров и контейнерам
  • Файлы и папки
  • Разрешения
  • Размер файла
  • Количество версий
  • Ограничения скорости API*
  • Запросы для каждого приложения, контейнера и пользователя*

Примечание.

Эти ограничения могут меняться. Проверьте текущие ограничения перед запуском в рабочую среду.

Ограничения размера

В SharePoint Embedded действуют следующие ограничения размера.

Ресурс Ограничение
Типы контейнеров, которые может создать клиент разработчика 25*
Типы контейнеров, которыми может владеть приложение 1
Хранилище на тип контейнера на клиента-потребителя 100 ТБ*
Files и папок в контейнере 30 миллионов
Хранилище в контейнере 25 ТБ
Files и папки с разрешениями на добавление в каждом контейнере 5,000
Размер файла 250 ГБ
Количество версий для каждого файла 500 (автоматическое ограничение журнала версий по умолчанию)
Количество пользователей, совместно используемых в папке или файле 5,000
Настраиваемые столбцы в контейнере 40

Звездочка (*) указывает на лимит, который можно увеличить.

Из типов контейнеров, создаваемых клиентом, один может быть бесплатным пробным типом контейнера для разработки и тестирования, а остальные — стандартными (оплачиваемыми) типами контейнеров. Новые клиенты начинают с более низкого значения по умолчанию, которое может быть повышено по запросу. Сведения о сравнении пробной версии со стандартом см. в статье Создание и настройка типа контейнера.

Проектирование с учетом ограничений типа контейнера

Приложению может принадлежать один тип контейнера.

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

Используйте контейнеры для экземпляров хранилища приложений внутри этого типа контейнера.

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

Сведения о планировании типов контейнеров см. в статье "Общие сведения о типах контейнеров и контейнерах".

Проектирование ограничений контейнеров

Контейнеры обеспечивают границу хранения и безопасности.

Спланируйте, сколько контейнеров может создать каждый клиент-потребитель.

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

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

Проектирование ограничений разрешений

SharePoint Embedded позволяет использовать до 5000 файлов и папок с разрешениями на добавление в контейнер.

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

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

Сведения о разрешениях см. в статье Проверка подлинности и разрешения плана.

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

Если приложения достигают пределов служб, SharePoint Embedded может вернуть:

  • Формат HTTP 429 Too Many Requests.
  • Формат HTTP 503 Server Too Busy.

Оба ответа Retry-After содержат заголовок.

Заголовок сообщает приложению, сколько времени ждать перед повторной попыткой или новым запросом.

Важно!

Количество отрегулированных запросов учитывается в ограничениях использования. Если игнорировать Retry-Afterэто , приложение может вызвать большее регулирование.

Руководство по повторной попытке

Реализуйте логику повтора, которая:

  • Обнаруживает HTTP 429 и 503.
  • Чтение Retry-After заголовка.
  • Ждет указанный срок, прежде чем повторить попытку.
  • Уменьшает параллелизм после регулирования.
  • Позволяет избежать немедленных циклов повторных попыток.
  • Позволяет избежать всплесков запросов после периода ожидания.

Используйте ограниченные повторные попытки и постоянные сбои поверхности для телеметрии операций. Общие рекомендации по обработке ответов регулирования см. в руководстве по регулированию Microsoft Graph.

Руководство по параллелизму

Уменьшение количества одновременных запросов при регулировании.

Избегайте шаблонов пакетов, отправляющих много запросов одновременно.

Распределяйте работу по времени при обработке больших наборов контейнеров или файлов.

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

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

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

Разные API имеют разную стоимость в зависимости от функциональности и сложности.

Стоимость нормализуется и выражается в единицах ресурсов.

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

Стоимость каждого запроса зависит от его сложности:

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

Примечание.

Затраты на единицу ресурса могут меняться.

Ограничения скорости API

SharePoint Embedded применяет эти ограничения скорости API.

Ресурс Ограничение
Запросов в контейнере 3000 единиц ресурсов в минуту
Количество запросов на приложение на клиента 12 000 единиц ресурсов в минуту*
Запросы на пользователя 600 единиц ресурсов в минуту

Звездочка (*) указывает на лимит, который можно увеличить.

Ограничения приложений определяются в единицах ресурсов.

Фактические запросы в минуту зависят от вызываемых вами API и стоимости единицы ресурса.

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

Ограничение скорости создания контейнеров

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

Затраты на операции с разрешениями

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

Операции, включающие в себя $expand=permissions , перечислены в пяти единицах ресурсов.

Сократите ненужное расширение разрешений.

Кэшируйте решения, основанные на разрешениях, только если это безопасно для модели безопасности.

Обновление данных о разрешениях при изменении членства или роли.

Соображения по пакетному управлению

Пакетное объединение может сократить накладные расходы на клиента, но не устраняет ограничения обслуживания или влияние на выставление счетов.

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

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

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

Рекомендации по увеличению производительности

Дизайн для:

  • Меньше звонков, требующих много разрешений.
  • Предсказуемый параллелизм.
  • Добавочная синхронизация.
  • Откат после регулирования.
  • Разделение работы переднего плана и фона.
  • Справедливость на уровне клиента для многотенантных приложений.
  • Мониторинг частоты запросов, кодов отклика и задержки.

О влиянии транзакций API на выставление счетов см. в статье "Выбор модели выставления счетов".

Операционный мониторинг

Трек:

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

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

Контрольный список планирования

  • Подтвердите текущие ограничения размера до запуска в производство.
  • Моделируйте контейнеры вместо того, чтобы создавать множество типов контейнеров.
  • Оцените хранилище для контейнера и клиента-пользователя.
  • Оценка количества файлов и папок.
  • Избегайте ненужных разрешений на добавление добавок.
  • Реализация Retry-After обработки для 429 и 503.
  • Ограничьте параллелизм и избегайте пиковых нагрузок.
  • Оценка использования единиц ресурса по типу операции.
  • Сократите количество операций, требующих больших разрешений.
  • Отслеживание регулирования и задержек.
  • Включение влияния на выставление счетов в разработку API.

Дальнейшие действия

Начните разработку с помощью краткого руководства: создайте свое первое приложение с помощью VS Code.

  • Last updated on