ビジネス ルール エンジン (BRE) パフォーマンスの最適化

BizTalk Server ソリューションでビジネス ルール エンジン (BRE) を実装する場合は、次の要素を考慮する必要があります。

ファクトの種類

ルール エンジンは、XML とデータベースのファクトにアクセスするのにかかる時間と比較して、.NET ファクトへのアクセスにかかる時間が短くなります。 ポリシーで .NET または XML またはデータベースファクトのいずれかを使用する場合は、パフォーマンスを向上させるために .NET ファクトを使用することを検討する必要があります。

データ テーブルとデータ接続

データ セットのサイズが小さい (< 10 個ほど) 場合、 TypedDataTable バインドは DataConnection バインディングよりもパフォーマンスが向上します。 ただし、 DataConnection バインドは、データ セットが大きい (約 10 行以上) 場合に 、TypedDataTable バインドよりも優れたパフォーマンスを発揮します。 したがって、データ セットの推定サイズに基づいて 、DataConnection バインディングと TypedDataTable バインディングのどちらを使用するかを決定する必要があります。

ファクトレトリマー

ファクト レトリーバーは、通常、ポリシーが実行される前にルール エンジンに長期的かつ緩やかに変化するファクトを提供するために使用される標準メソッドを実装します。 エンジンはこれらのファクトをキャッシュして、複数の実行サイクルで使用します。 ルール エンジンを呼び出すたびに静的またはかなり静的なファクトを送信するのではなく、ファクトを初めて送信するファクト レトリーバーを作成し、必要な場合にのみメモリ内のファクトを更新する必要があります。

ルールの優先度

ルールの優先度設定は 、0 の両側で範囲を指定でき、数値が大きいほど優先度が高くなります。 アクションは、優先度が最も高いものから最も低い優先度の順に実行されます。 Assert/Update 呼び出しを使用してポリシーが前方チェーン動作を実装する場合は、優先度設定を使用してチェーンを最適化できます。 たとえば、 Rule2 が Rule1 によって設定された値に依存しているとします。 Rule1 の優先度を高くすると、Rule2 は Rule1 が起動して値を更新した後にのみ実行されます。 逆に、 Rule2 の優先度が高い場合は、1 回起動してから、 Rule1 の起動後にもう一度起動し、 Rule2 が条件を使用しているという事実を更新できます。 これにより正しい結果が得られますが、このシナリオで Rule1 の優先度を高くすると、パフォーマンスが向上します。

呼び出しを更新する

Update 関数を使用すると、更新されたファクトを使用するすべてのルールが再評価されます。 更新関数の呼び出しは、特にファクトの更新時に大量のルールセットが再評価される場合にコストがかかる場合があります。 この動作を回避できる状況があります。 たとえば、次の規則を考えてみましょう。

Rule1:

IF PurchaseOrder.Amount > 5   
THEN StatusObj.Flag = true; Update(StatusObj)  

Rule2:

IF PurchaseOrder.Amount <= 5   
THEN StatusObj.Flag = false; Update(StatusObj)  

ポリシーの残りのルールはすべて、 条件で StatusObj.Flag を使用します。 したがって、StatusObj オブジェクトで Update が呼び出されると、すべてのルールが再評価されます。 Amount フィールドの値が何であれ、Rule1 または Rule2 を除くすべてのルールは、Update 呼び出しの前と Update 呼び出しの後に 1 回、2 回評価されます。

関連するオーバーヘッドを軽減するために、ポリシーを呼び出す前に フラグ フィールドの値を false に設定し、ポリシーで Rule1 のみを使用してフラグを設定できます。 この場合、Amount フィールドの値が 5 より大きい場合にのみ Update が呼び出され、Amount の値が 5 以下の場合は Update 関数は呼び出されません。 したがって、Rule1 または Rule2 を除くすべてのルールは、Amount フィールドの値が 5 より大きい場合にのみ 2 回評価されます。

論理 OR 演算子の使用

条件内で論理 OR 演算子の数を増やすと、順列が追加されてルール エンジンの分析ネットワークが拡大されます。 パフォーマンスの観点から、条件は論理 OR 演算子を含まないアトミック ルールに分割した方が適切です。

キャッシュ設定

ルール エンジンは 2 つのキャッシュを使用します。 最初の 1 つは更新サービスによって使用され、2 つ目は各 BizTalk プロセスで使用されます。 ポリシーを初めて使用すると、BizTalk プロセスは更新サービスにポリシー情報を要求します。 更新サービスは、ルール エンジン データベースからポリシー情報を取得し、キャッシュして BizTalk プロセスに情報を返します。 BizTalk プロセスは、その情報に基づいてポリシー オブジェクトを作成し、関連付けられているルール エンジン インスタンスがポリシーの実行を完了すると、ポリシー オブジェクトをキャッシュに格納します。 同じポリシーが再度呼び出されると、BizTalk プロセスはキャッシュからポリシー オブジェクトを再利用します (使用可能な場合)。 同様に、BizTalk プロセスが更新サービスからポリシーに関する情報を要求した場合、更新サービスは使用可能な場合、キャッシュ内のポリシー情報を検索します。 更新サービスでは、60 秒ごとに、データベース内のポリシーに対する更新があったかどうかも確認されます。 更新プログラムがある場合、更新サービスは情報を取得し、更新された情報をキャッシュします。

これらのキャッシュに関連するルール エンジンには、 CacheEntries、 CacheTimeout、 PollingInterval の 3 つのチューニング パラメーターがあります。 これらのパラメーターの値は、レジストリまたは構成ファイルで指定できます。 CacheEntries パラメーターの値は、キャッシュ内のエントリの最大数であり、既定では 32 に設定されます。 CacheEntries パラメーターの値を大きくして、特定のシナリオでのパフォーマンスを向上させることができます。 たとえば、40 個のポリシーを繰り返し使用しているとします。 CacheEntries パラメーターの値を 40 に増やして、パフォーマンスを向上させることができます。 これにより、更新サービスは最大 40 個のポリシーのキャッシュの詳細をメモリに保持できます。

CacheTimeout の値は、更新サービス キャッシュでエントリが保持される時間 (秒単位) です。 つまり、 CacheTimeout 値は、ポリシーのキャッシュ エントリが参照されずにキャッシュに保持される期間を指します。 CacheTimeout パラメーターの既定値は、3600 秒 (1 時間) です。 つまり、キャッシュ エントリが 1 時間以内に参照されていない場合、エントリは削除されます。 場合によっては、パフォーマンスを向上させるために CacheTimeout パラメーターの値を増やすことが有益な場合があります。 たとえば、ポリシーが 2 時間ごとに呼び出される場合、 CacheTimeout パラメーターを 2 時間より大きい値に増やすことで、ポリシー実行のパフォーマンスが向上します。

ルール エンジンの PollingInterval パラメーターは、更新サービスが更新のためにルール エンジン データベースをチェックする時間を秒単位で定義します。 PollingInterval パラメーターの既定値は 60 秒です。 ポリシーがまったく更新されないか、ほとんど更新されないことがわかっている場合は、このパラメーターを高い値に変更してパフォーマンスを向上させることができます。

SideEffects プロパティ

ClassMemberBinding、DatabaseColumnBinding、および XmlDocumentFieldBinding クラスには、SideEffects という名前のプロパティがあります。 このプロパティは、バインドされるフィールド、メンバー、または列の値をキャッシュするかどうかを決定します。 DatabaseColumnBinding クラスおよび XmlDocumentFieldBinding クラスの SideEffects プロパティの既定値は false です。 ClassMemberBinding クラスの SideEffects プロパティの既定値は true です。 したがって、XML ドキュメントのフィールドまたはデータベース テーブルの列がポリシー内で 2 回目以降にアクセスされたときには、その値がキャッシュから取得されます。 一方、.NET オブジェクトのメンバーが 2 回目以降にアクセスされたときには、値がキャッシュからではなく .NET オブジェクトから取得されます。 .NET ClassMemberBinding の SideEffects プロパティを false に設定すると、フィールドの値が 2 回目以降にキャッシュから取得されるため、パフォーマンスが向上します。 この設定は、プログラムでしか行うことができません。 ビジネス ルール Composer ツールでは 、SideEffects プロパティは 公開されません。

インスタンスと選択性

XmlDocumentBinding、ClassBinding、および DatabaseBinding クラスには、インスタンスと選択性の 2 つのプロパティがあります。 Instances の値は、作業メモリ内のクラス インスタンスの予想される数です。 [選択性] の値は、ルールの条件を正常に渡すクラス インスタンスの割合です。 ルール エンジンは、これらの値を使用して、まず最小限のインスタンスが条件の評価に使用され、その後で残りのインスタンスが使用されるように、条件の評価を最適化します。 オブジェクトのインスタンス数に関する知識がある場合は、 Instances プロパティをその値に設定すると、パフォーマンスが向上します。 同様に、これらのオブジェクトの割合が条件を満たしていることを事前に知っている場合は、その値に [選択性] プロパティを設定すると、パフォーマンスが向上します。 これらのパラメーターの値は、プログラムでのみ設定できます。 ビジネス ルール作成ツールでは、これらのパラメーターが公開されません。

参照

BizTalk Server パフォーマンスの最適化