メインコンテンツにスキップ

Performance Optimization

数百万のユーザーや権限を持つ本番環境で適用すると、Casbinの強制実行でパフォーマンスが低下する可能性があります。 通常、原因は2つあります：

高トラフィック量​

1秒あたりの着信リクエスト数が大きすぎる、例えば、1つのCasbinインスタンスで1秒あたり10,000リクエスト。 このような場合、1つのCasbinインスタンスだけではすべてのリクエストを処理するのに十分ではないことがよくあります。 2つの可能な解決策があります：

  1. マルチスレッドを使用して複数のCasbinインスタンスを有効にし、マシンのすべてのコアをフルに活用します。 詳細については、次を参照してください：マルチスレッド。

  2. Casbinインスタンスをクラスタ（複数のマシン）にデプロイし、Watcherを使用してすべてのCasbinインスタンスが一貫していることを確認します。 詳細については、次を参照してください：Watchers。

メモ

上記の両方の方法を同時に使用することができます。例えば、Casbinを10台のマシンのクラスタにデプロイし、各マシンが同時に5つのスレッドでCasbinの強制リクエストを処理します。

ポリシールールの数が多い​

クラウド環境やマルチテナント環境では、数百万のポリシールールが必要になることがあります。 強制呼び出しや初期時間のポリシールールのロードは非常に遅くなることがあります。 このような場合は、通常、いくつかの方法で緩和することができます：

  1. Casbinモデルやポリシーが適切に設計されているか確認します。 適切に書かれたモデルとポリシーは、各ユーザー/テナントの重複したロジックを抽象化し、ルールの数を非常に小さなレベル（\< 100）に減らします。 例えば、すべてのテナント間でいくつかのデフォルトルールを共有し、後でユーザーが自分のルールをカスタマイズできるようにすることができます。 カスタマイズされたルールはデフォルトのルールを上書きすることができます。 さらなる質問がある場合は、CasbinリポジトリのGitHub issueを開いてください。

  2. シャーディングを行い、Casbinエンフォーサーがポリシールールの小さなセットだけをロードするようにします。 例えば、enforcer_0はtenant_0からtenant_99までをサービスし、enforcer_1はtenant_100からtenant_199までをサービスすることができます。 すべてのポリシールールの一部だけをロードするには、次を参照してください：Policy Subset Loading。

  3. RBACロールに直接ユーザーではなく権限を付与します。 CasbinのRBACは、ロール継承ツリー（キャッシュとして）によって実装されています。 したがって、Aliceのようなユーザーが与えられた場合、CasbinはRBACツリーをO(1)時間でクエリし、ロールユーザー関係と強制実行を行います。 あなたのgルールが頻繁に変更されないなら、RBACツリーを常に更新する必要はありません。 この議論の詳細はこちらで見ることができます：https://github.com/casbin/casbin/issues/681#issuecomment-763801583

メモ

上記のすべての方法を同時に試すことができます。