适用于: 开发 人员
在生成大容量容器和内容操作之前,请使用本文来规划 SharePoint Embedded 调用模式。 SharePoint Embedded 将吞吐量表示为 每分钟资源单位 (规范化请求成本模型) 而不是固定每秒请求数速率; API 速率限制 部分说明如何将资源单位转换为预期的请求速率。
通过Microsoft支持人员或 SharePoint Embedded 载入联系人,可以根据请求增加标有 * 的限制;在生产环境中处理限制之前,请计划默认限制并请求增加。
限制类别
SharePoint Embedded 限制影响:
- *容器类型计数
- *容器计数
- 每个容器类型和容器的存储
- 文件和文件夹
- 权限
- 文件大小
- 版本计数
- *API 速率限制
- *每个应用、容器和用户的请求数
注意
这些限制可能会更改。 在启动到生产环境之前,请验证当前限制。
大小限制
SharePoint Embedded 强制实施以下大小限制。
| 资源 | 限制 |
|---|---|
| 合作伙伴租户可以创建的容器类型 | 25* |
| 应用可以拥有的容器类型 | 1 |
| 每个使用租户的容器类型为容器 | 100k* |
| 每个使用租户的每个容器类型的存储 | 100 TB* |
| 每个容器Files和文件夹 | 30M |
| 每个容器的存储 | 25 TB |
| 每个容器具有附加权限的Files和文件夹 | 5k |
| 文件大小 | 250 GB |
| 每个文件的版本计数 | 500 (自动版本历史记录限制默认设置) |
| 每个文件夹或文件共享的用户数 | 5k |
星号 (*) 指示可以请求增加的限制。
在租户创建的容器类型中,一种可以是用于开发和测试的免费 试用版容器类型 ,其余类型是 标准 () 容器类型计费。 新租户以较低的默认值开头,可按请求引发。 有关试用版与标准的详细信息,请参阅 创建和配置容器类型。
针对容器类型限制进行设计
一个应用可以拥有一种容器类型。
不要将每个客户、项目、工作区或用户建模为单独的容器类型。
将容器用于容器类型中的应用程序存储实例。
为应用级行为、访问关系和计费责任选择容器类型。
有关容器类型规划,请参阅 了解容器类型和容器。
针对容器限制进行设计
容器提供存储和安全边界。
规划每个使用租户可以创建的容器数。
考虑可能影响配额或存储的活动容器和任何已删除的容器生命周期。
使容器边界与访问、生命周期和治理要求保持一致。
权限限制设计
SharePoint Embedded 允许每个容器具有附加权限的最多 5,000 个文件和文件夹。
当容器级别或文件夹级模型足够时,请避免将每个文件或文件夹设计为具有唯一权限。
尽可能使用容器成员身份和角色。
有关权限概念,请参阅 规划身份验证和权限。
限制响应
当应用程序达到服务限制时,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 速率限制。
| 资源 | 限制 |
|---|---|
| 每个容器的请求数 | 每分钟 3k 个资源单位 |
| 每个租户每个应用的请求数 | 每分钟 12000 个资源单位* |
| 每个用户的请求数 | 每分钟 600 个资源单位 |
星号 (*) 指示可以请求增加的限制。
应用程序限制以资源单位定义。
每分钟的实际请求数取决于调用的 API 及其资源单位成本。
若要估算请求速率,请平均每个请求大约两个资源单位,并将应用程序资源单位限制除以 2。
容器创建速率限制
每个使用租户,在租户的高峰时段,容器创建限制为每秒 5 个新容器。 超出此限制的请求速率受限。 在高峰时段之外,可以更快地创建容器。
权限操作成本
权限资源操作的资源单位成本较高。
包含 $expand=permissions 的操作在五个资源单位中列出。
减少不必要的权限扩展。
仅当权限派生的决策对安全模型是安全的时缓存的。
发生成员身份或角色更改时刷新权限数据。
批处理注意事项
批处理可以减少客户端开销,但不会消除服务限制或计费影响。
估算资源单位消耗量和事务成本时,对每个基础操作进行计数。
避免在短间隔内针对一个容器、应用、租户或用户创建过多工作集中的批处理。
根据平台返回的响应详细信息,对批处理操作执行限制响应。
性能注意事项
设计用于:
- 更少的权限密集型调用。
- 可预测的并发性。
- 增量同步。
- 限制后退避。
- 前台工作和后台工作分离。
- 多租户应用的租户级公平性。
- 监视请求速率、响应代码和延迟。
有关 API 事务的计费影响,请参阅 选择计费模型。
操作监视
跟踪:
- HTTP
429和503响应速率。 - 重试计数和等待持续时间。
- 资源密集型操作。
- 按应用、租户、用户和容器发出的请求。
- 后台作业队列长度。
- 每个容器和租户的存储增长。
- 权限操作频率。
使用这些信号来优化并发性,并确定需要设计更改的租户或工作流。
计划清单
- 在生产启动之前确认当前大小限制。
- 对容器进行建模,而不是创建许多容器类型。
- 估计每个容器和每个使用租户的存储。
- 估计文件和文件夹计数。
- 避免不必要的累加权限。
- 实现
Retry-After和503的429处理。 - 限制并发并避免峰值。
- 按操作类型估计资源单位使用情况。
- 减少权限密集型操作。
- 监视限制和延迟。
- 在 API 设计中包括计费影响。
相关规划文章
后续步骤
使用快速入门开始生成 :使用 VS Code 生成第一个应用。