制限と呼び出しパターン
このドキュメントでは、パブリック プレビュー中の SharePoint Embedded の制限について説明します。
注:
これらはプレビューの制限であり、変更される可能性があります。
サイズの制限
次の表は、コンテナーのサイズ制限を定義しています"
リソース | 極限 |
---|---|
パートナー テナントが作成できるコンテナーの種類 | 5* |
アプリが所有できるコンテナーの種類 | 1 |
使用しているテナントごとのコンテナーの種類のコンテナー | 100k* |
使用しているテナントごとのコンテナーの種類ごとのストレージ | 100 TB* |
コンテナーあたりのファイルとフォルダー | 30M |
コンテナーごとのストレージ | 25 TB |
コンテナーごとの追加アクセス許可を持つファイルとフォルダー | 5k |
ファイルのサイズ | 250 GB |
ファイルあたりのバージョン数 | 500 (自動バージョン履歴の制限の既定の設定) |
フォルダーまたはファイルごとに共有されるユーザーの数 | 5k |
注:
要求ごとに制限を増やすことができます。
調整
パターンとベスト プラクティス
アプリケーションがサービスの制限に達すると、HTTP 状態コード 429 ("要求が多すぎます") が表示されます。 HTTP 状態コード 503 ("サーバーがビジー") を受け取る場合もあります。
一般に、調整を処理するためのベスト プラクティスは次のとおりです。
- 同時要求の数を減らします。
- 要求の急増を避けます。
-
Retry-After
HTTP ヘッダーを使用します。
どちらの場合も、Retry-After
ヘッダーが応答に含まれ、呼び出し元のアプリケーションが再試行または新しい要求を行う前に待機する時間を示します。 調整された要求は使用制限にカウントされるため、 Retry-After
を受け入れられなかった場合、調整が増える可能性があります。
API レートの制限
SharePoint Embedded には、さまざまな API が用意されています。 API の機能と複雑さに応じて、異なる API のコストが異なります。 API のコストは正規化され、リソース ユニットによって表されます。 API レートの制限は、リソース ユニットを使用して定義することもできます。
要求あたりのリソース ユニット数 | 操作 |
---|---|
1 | アイテムの取得などの単一アイテム クエリ |
2 | リストの子の作成、更新、削除、アップロードなどの複数項目のクエリ |
5 | $expand=permissions を含むすべてのアクセス許可リソース操作 |
注:
API リソース ユニットのコストを変更する権利を留保します。
次の表に、アプリケーションとコンテナーの API レート制限を示します。
リソース | 制限 |
---|---|
コンテナーあたりの要求数 | 1 分あたり 3,000 のリソース ユニット |
テナントごとのアプリあたりの要求数 | 1 分あたり 12,000 リソース ユニット* |
ユーザーあたりの要求数 | 1 分あたり 600 リソース ユニット |
注:
* 要求ごとに制限を増やすことができます。
アプリケーションの制限はリソースユニットで定義され、1 分あたりの要求数などの実際の要求レートは、選択した API とそれに対応するリソースユニットコストによって異なります。 一般に、要求ごとに約 2 つのリソース ユニットを平均し、アプリケーション リソース ユニットの制限を 2 で割ることで、要求率を見積もることができます。 アクセス許可操作の使用量を減らすと、特に呼び出し速度が向上します。これらの操作は、リソースの全体的な消費量に最も大きな影響を与えます。