使用する
依存関係
従来のqRFCモデルは、データがRFCスケジューラによって処理される場合にのみ、個々のユニット間の依存関係を検出します。アウトバウンドスケジューラは、宛先ごとに、この宛先のデータを処理するスケジューラを開始します。
スケジューラーは、処理がすべての宛先で一貫していることを保証するために、限られた期間だけ各宛先で実行されます。このため、スケジューラは宛先を処理する前に毎回シーケンスを再決定する必要があります。
対照的に、bgRFCでは、データが保存されるときに依存関係が決定されます。そうすることで、RFCスケジューラーは、最小限の労力で即座に実行できるすべてのユニットを見つけることができ、すべての依存関係は1回だけ検出されます。データを保存する際の追加の作業は、データベース設計の効率的なアルゴリズムと最適化によって大幅に補われます。
クライアントごとに、キューに入れられた負荷を並行して処理する定義された数のアウトバウンドスケジュールが開始されますが、ターゲットシステムの負荷はより短い間隔で決定されるため、以前よりも正確になります。
ユニットとキューの削除手順
従来の手順とは異なり、ユニットまたはキューが削除された場合、ユニットには最初にフラグが付けられ、次にスケジューラによって削除されるため、依存関係は保持されます。
Unit4を削除した後、Unit6はUnit3の後でのみ実行できます。これは、Unit4はスケジューラーがUnit3を処理した後にのみ削除されるためです。queue2を削除すると、次の状況が発生します。
Unit6はUnit2の後に実行されます。選択したすべてのユニットがスケジューラによって削除されます。
ゲートウェイ
ボトルネックのもう1つの潜在的な原因であるゲートウェイも最適化されています。新しい概念は、アプリケーションサーバーで同時に実行できるアウトバウンドスケジューラの最大数と、すべてのRFCスケジューラが使用できる接続の最大数を規制します。この制限により、ローカルゲートウェイが過負荷になるのを防ぎます。
宛先のゲートウェイは、各送信側システムの並列アウトバウンドスケジューラーの数とそれらの接続の最大数を構成可能にすることにより、過負荷からも保護されます。
パフォーマンスへの影響
新しいbgRFC設計で実装された改善は、各宛先に多数の依存ユニットがある場合、主に高負荷状態で顕著になります。初めて、RFCデータ処理で線形対数スケーラビリティ（システム容量に依存）が可能になりました。
キューイング機能のトランザクション動作では、個々のユニットが処理されているときに大幅な節約はできませんが、より多くのまたはより高速なハードウェアを適用すると、スループットがより顕著になります。制限要因は、データベースのパフォーマンスとユニットの処理速度です。
さらに、新しいAPIも最適化された手順に貢献します。冗長な関数が削除され、古いAPIの制限の一部が適用されなくなりました。これにより、サポートチームと開発チームの両方の時間と労力を削減する、よりスムーズで効率的なコンセプトが実現しました。
