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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

drools-metric モジュールを使用すると、特に多くのルールを処理する場合に、遅いルールを特定できます。drools-metric モジュールは、デシジョンエンジンのパフォーマンスの分析にも役立ちます。drools-metric モジュールは、実稼働環境で使用するためのものではないことに注意してください。ただし、テスト環境で分析を実行することはできます。

drools-metric を使用して意思決定エンジンのパフォーマンスを分析するには、最初に drools-metric をプロジェクトの依存関係に追加します。

<dependency>
  <groupId>org.drools</groupId>
  <artifactId>drools-metric</artifactId>
</dependency>

<dependency>
  <groupId>org.drools</groupId>
  <artifactId>drools-metric</artifactId>
</dependency>

drools-metric を使用してトレースログを有効にする場合は、次の例に示すように、org.drools.metric.util.MetricLogUtils のロガーを設定します。

<configuration>
  <logger name="org.drools.metric.util.MetricLogUtils" level="trace"/>
  ...
<configuration>

<configuration>
  <logger name="org.drools.metric.util.MetricLogUtils" level="trace"/>
  ...
<configuration>

または、drools-metric を使用して、Micrometer を使用してデータを公開できます。データを公開するには、次の例に示すように、選択した Micrometer レジストリーを有効にします。

<dependency>
  <groupId>io.micrometer</groupId>
  <artifactId>micrometer-registry-jmx</artifactId> <!-- Discover more registries at micrometer.io. -->
</dependency>

<dependency>
  <groupId>io.micrometer</groupId>
  <artifactId>micrometer-registry-jmx</artifactId> <!-- Discover more registries at micrometer.io. -->
</dependency>

  Metrics.addRegitry(new JmxMeterRegistry(s -> null, Clock.SYSTEM));

  Metrics.addRegitry(new JmxMeterRegistry(s -> null, Clock.SYSTEM));

ロギングと Micrometer のどちらを使用するかに関係なく、システムプロパティー drools.metric.logger.enabled を true に設定して MetricLogUtils を有効にする必要があります。オプションで、drools.metric.logger.threshold システムプロパティーを設定することで、メトリクスレポートのマイクロ秒単位のしきい値を変更できます。

ロギングを使用するように drools-metric を設定した後、ルールを実行すると、次の例に示すようにログが生成されます。

TRACE [JoinNode(6) - [ClassObjectType class=com.sample.Order]], evalCount:1000, elapsedMicro:5962
TRACE [JoinNode(7) - [ClassObjectType class=com.sample.Order]], evalCount:100000, elapsedMicro:95553
TRACE [ AccumulateNode(8) ], evalCount:4999500, elapsedMicro:2172836
TRACE [EvalConditionNode(9)]: cond=com.sample.Rule_Collect_expensive_orders_combination930932360Eval1Invoker@ee2a6922], evalCount:49500, elapsedMicro:18787

TRACE [JoinNode(6) - [ClassObjectType class=com.sample.Order]], evalCount:1000, elapsedMicro:5962
TRACE [JoinNode(7) - [ClassObjectType class=com.sample.Order]], evalCount:100000, elapsedMicro:95553
TRACE [ AccumulateNode(8) ], evalCount:4999500, elapsedMicro:2172836
TRACE [EvalConditionNode(9)]: cond=com.sample.Rule_Collect_expensive_orders_combination930932360Eval1Invoker@ee2a6922], evalCount:49500, elapsedMicro:18787

この例には、次の主要なパラメーターが含まれています。

未処理の evalCount または elapsedMicro ログが見つかった場合は、ノード名を ReteDumper.dumpAssociatedRulesRete() 出力と関連付けて、ノードに関連付けられているルールを識別します。

ReteDumper.dumpAssociatedRulesRete(kbase);

ReteDumper.dumpAssociatedRulesRete(kbase);

[ AccumulateNode(8) ] : [Collect expensive orders combination]
...

[ AccumulateNode(8) ] : [Collect expensive orders combination]
...