グループ内のすべてのサーバーにわたって収集されたメトリックに基づいて、スロットルメカニズムが開始され、メンバーが新しいトランザクションを実行/コミットできるレートを制限するかどうかが決定されます。

したがって、すべてのメンバーから取得されたメトリックは、各メンバーの容量を計算するための基準となります: メンバーに大規模なキュー (証明またはアプライヤスレッド用) がある場合、新しいトランザクションを実行するための容量は、最後の期間に動作保証または適用された容量に近い必要があります。

グループ内のすべてのメンバーの最小容量によってグループの実際の容量が決まりますが、ローカルトランザクションの数によって書込み中のメンバーの数が決まり、その結果、使用可能な容量を共有するメンバーの数が決まります。

これは、すべてのメンバーが使用可能な容量に基づいて書込み割当て制限を確立していることを意味します。つまり、次の期間に安全に発行できるトランザクションの数が多くなります。 ライター割当て制限は、証明者またはバイナリログアプライアンスのキューサイズがユーザー定義のしきい値を超えると、スロットルメカニズムによって強制されます。

割当て制限は、前の期間に遅延したトランザクションの数だけ削減され、さらに 10% 削減されて、問題をトリガーしたキューのサイズを縮小できるようになります。 キューサイズがしきい値を超えるとスループットのジャンプが大きくならないようにするために、スループットはその後の期間ごとに同じ 10% 増加することのみが許可されます。

現在のスロットルメカニズムでは、割当て制限を下回るトランザクションはペナル化されませんが、監視期間が終了するまで、それを超えるトランザクションの終了は遅延されます。 その結果、発行された書込みリクエストの割当て制限が非常に小さい場合、一部のトランザクションで待機時間が監視期間に近い可能性があります。