次の方法で共有

ルール エンジン使用時のパフォーマンスに関する考慮事項

  • [アーティクル]

このトピックでは、各種のシナリオで構成パラメーターやチューニング パラメーターにさまざまな値を指定した場合のルール エンジンのパフォーマンスについて説明します。

ファクトの種類

ルール エンジンは、XML とデータベースのファクトにアクセスする場合よりも、.NET ファクトにアクセスする時間が短くなります。 ポリシーで使用するファクトを .NET のファクト、XML のファクト、またはデータベースのファクトの中から選択できる場合は、パフォーマンスを高めるために .NET のファクトを使用することを検討してください。

データ テーブル バインドとデータ接続バインド

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

ファクト レトリワー

ファクトレトリバーは、標準メソッドを実装し、通常はそれらを使用して、ポリシーが実行される前にルール エンジンに長期的かつゆっくりと変化するファクトを提供するオブジェクトです。 エンジンはこれらのファクトをキャッシュして、複数の実行サイクルで使用します。 静的なファクトやほぼ静的なファクトをルール エンジンの起動時に毎回送信するのではなく、初回にファクトを送信した後は必要時にのみメモリ内のファクトを更新するファクト取得コンポーネントを作成することをお勧めします。

ルールの優先順位

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

Update 呼び出し

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 回評価されます。

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

論理 OR 演算子の使用

ルール エンジンは、論理 AND 演算子を実行するために最適化されており、論理 AND 演算子を解析した規則を結合標準形式で再構築し、 OR 演算子が最上位レベルでのみ使用されるようにします。 条件で論理 OR 演算子の数を増やすと、ルール エンジンの分析ネットワークを拡張する追加の順列が作成され、ルール エンジンがルールを正規化するのに長い時間がかかる場合があります。 次の一覧は、この問題を回避する手段を示しています。

  • OR 演算子が最上位レベルのみになるように、規則を非結合の標準形式に変更します。 ビジネス ルール作成ツールで選言標準形のルールを開発することは困難なことがあります。 プログラムでルールを作成することもできます。

  • OR 操作を実行し、ブール値を返し、ルールで コンポーネントを使用するヘルパー コンポーネントを開発します。

  • ルールを複数のルールに分割し、そのルールによって、以前実行されたルールで設定されたフラグをチェックするか、次の例に示すように、以前実行されたルールでアサートされたオブジェクトを使用する。

    • 規則 1: IF (a == 1 OR a == 3) THEN b = true

      ルール 2: if (b == true) THEN ...

    • 規則 1: IF (a == 1 OR a == 3) THEN assert(new c())

      規則 2: IF (c.flag == true) THEN ...

キャッシュの設定

ルール エンジンは 2 つのキャッシュを使用します。 1 つは更新サービス内にあり、もう 1 つは各 BizTalk プロセス内にあります。 ポリシーが最初に使用されるときに、BizTalk プロセスは更新サービスにポリシー情報を要求します。 更新サービスは、ルール エンジン データベースからポリシー情報を取得してキャッシュし、BizTalk プロセスにその情報を返します。 BizTalk プロセスは、この情報を基にポリシー オブジェクトを作成し、関連するルール エンジン インスタンスがポリシーの実行を完了した時点でそのポリシー オブジェクトをキャッシュに格納します。 同じポリシーが再び呼び出されたときに、キャッシュ内にポリシー オブジェクトがあれば、BizTalk プロセスはそれを再利用します。

同様に、BizTalk プロセスがポリシーに関する情報を更新サービスに要求すると、更新サービスはまずそのキャッシュ内でポリシー情報を検索します。 また更新サービスは、データベース内でポリシーが更新されていないかを 60 秒 (1 分)ごとにチェックします。 更新があった場合、更新サービスは更新された情報を取得してキャッシュします。

これらのキャッシュに関連するルール エンジンには、 CacheEntries、 CacheTimeout、 PollingInterval の 3 つのチューニング パラメーターがあります。 これらのパラメーターの値は、レジストリまたは構成ファイルで指定できます。

CacheEntries の値は、キャッシュ内のエントリの最大数です。 CacheEntries の既定値は 32 です。 場合によっては、 CacheEntries パラメーターの値を大きくしてパフォーマンスを向上させることができます。 たとえば、40 個のポリシーを繰り返し使用するとします。 この場合は、パフォーマンスを向上させるために CacheEntries の値を 40 に増やします。 この設定により、更新サービスは最大 40 個のポリシーの詳細をメモリにキャッシュできるようになります。 また、BizTalk サービスが最大 40 個のポリシー インスタンスをメモリにキャッシュできるようになります。 BizTalk サービスのキャッシュに、同じポリシーのインスタンスを複数格納できます。

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

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

SideEffects プロパティ

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

Instances と Selectivity

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