第8章 DRL 使用時のパフォーマンスチューニングに関する考慮点

以下の主要な概念または推奨のプラクティスを使用すると、DRL ルールとデシジョンエンジンのパフォーマンス最適化に役立ちます。本セクションでこの概念についてまとめており、随時、他のドキュメントを相互参照して詳細を説明します。本セクションは、Red Hat Process Automation Manager の新しいリリースで、必要に応じて拡張または変更します。

パターンの制約のプロパティーおよび値は左から右方向に定義する

DRL パターンの制約では、ファクトプロパティー名は演算子の左側に、値 (定数または変数) は右側に配置されるようにします。プロパティー名は常に、インデックスの値ではなく、キーでなければなりません。たとえば、Person( "John" == firstName ) ではなく Person( firstName == "John" ) のように指定します。制約のプロパティーと値を右から左に定義すると、デシジョンエンジンのパフォーマンスが低下する可能性があります。

DRL パターンおよび制約の詳細については、「DRL のルール条件 (WHEN) 」 を参照してください。

パターン制約では他の演算子よりも等価演算子タイプをできるだけ使用する
デシジョンエンジンは、ビジネスルールロジックの定義に使用可能な DRL 演算子タイプを多数サポートしていますが、等価演算子 == の評価を最も効率的に実行します。実用的な場合には、他の演算子ではなく、この演算子を使用してください。たとえば、パターン (Person( firstName == "John" )) は Person( firstName != "OtherName" ) よりも効率的に評価されます。等価演算子だけを使用すると実用的ではない場合があるので、DRL 演算子を使用するときはビジネスロジックの要件とオプションをすべて検討してください。
最も制限の厳しいルールの条件を先にリストする

ルールに複数の条件がある場合には最も制限の厳しい条件から順にリストしてください。こうすることで、最も制限の厳しい条件が満たされていない場合は、デシジョンエンジンがすべての条件セットを評価せずに済むようになります。

たとえば、以下の条件は、航空券とホテルをあわせて予約した旅行者には割引を適用する旅行予約ルールの一部です。このシナリオでは、ホテルを予約するお客様がこの割引を受けるために航空券をあわせて予約することはほぼないので、ホテルの条件はほぼ満たされず、このルールは実行されません。そのため、必要のない航空券の条件を頻繁に評価しないので、1 つ目の条件の順番のほうがより効率的です。これは、1 つ目の条件では、ホテルの条件が満たされていない場合に不必要かつ頻繁に、航空券の条件をデシジョンエンジンが評価せずに済むからです。

優先条件の順番: ホテルと航空券

when
  $h:hotel() // Rarely booked
  $f:flight()

効率の悪い条件の順番: 航空券とホテル

when
  $f:flight()
  $h:hotel() // Rarely booked

DRL パターンおよび制約の詳細については、「DRL のルール条件 (WHEN) 」 を参照してください。

from 句を過剰に使用する、サイズの大きいオブジェクトコレクションで反復を回避する

以下の例のように、サイズの大きいオブジェクトコレクションで反復を行う DRL ルールでは from 要素の使用を回避してください。

from 句を使用した条件の例

when
  $c: Company()
  $e : Employee ( salary > 100000.00) from $c.employees

このような場合には、デシジョンエンジンはルールの条件が評価されるたびにサイズの大きいグラフを反復するので、ルール評価の妨げになります。

他の手段として以下の例のように、サイズの大きいグラフが含まれるオブジェクトを追加してデシジョンエンジンが頻繁に反復作業を行うのではなく、コレクションを KIE セッションに直接追加して、条件内でコレクションを結合します。

from 句なしの条件の例

when
  $c: Company();
  Employee (salary > 100000.00, company == $c)

この例では、デシジョンエンジンは 1 回だけリストを反復して、ルールの評価を効率化します。

from 要素または他の DRL 条件要素に関する情報は、「DRL でサポートされるルール条件要素 (キーワード)」を参照してください。

ロギングのデバッグには、System.out.println ステートメントの代わりに、デシジョンエンジンのイベントリスナーをルール内で使用します。

ルールのデバッグやコンソール出力に、System.out.println ステートメントをルールアクションで使用できますが、多数のルールに対してこれを行うと、ルール評価の妨げになります。別の効率的な方法として、できるだけ内蔵のデシジョンエンジンイベントリスナーを使用してください。このイベントリスナーが貴社の要件に満たない場合には、Logback、Apache Commons Logging または Apache Log4j など、デシジョンエンジンがサポートするシステムロギングユーティリティーを使用してください。

サポート対象のデシジョンエンジンのイベントリスナーおよびロギングユーティリティーに関する詳細は、「Red Hat Process Automation Manager のデシジョンエンジン」を参照してください。