If you do nothing heavy in the RHS, indeed, rules' action part execution is
faster than fact insertion, but this is because of your design, not something
relevant for all usages.
In an inference system using RETE like drools, the most of time is spent to
update the RETE network. Updates of this network is done at
insert/retract/modify, and these actions can be called from outside OR inside
the rules RHS.
In an inference system, you may be interested by chaining, ie your rules' RHS
do modify the fact base heavily, and thus the RHS exec takes time.
What you describe in your post is almost a sequential behaviour, ie rules exec
does not modify the fact base.
I agree that this is a very common usage, but you can't oppose fact insertion
and RHS execution without the precision of your design choices, which can be
too restrictive for other usages that require chaining.
----- Original Message -----
From: "Stephen Masters" <stephen.mast...@me.com>
To: "Rules Users List" <rules-users@lists.jboss.org>
Sent: Friday, August 17, 2012 3:54:41 PM
Subject: Re: [rules-users] A few general questions on scaling
StatefulKnowledgeSessions
Actually, I do mean that! :D
But maybe I should explain…
To be more precise, most of the time in my apps is taken in marshalling facts
and inserting them into the session. From firing rules, it tends to take 10s of
microseconds for a decision to be made.
Obviously if the RHS is doing more than just making a decision based on facts
already in the system (i.e. the RHS code queries databases, etc) then firing
can get very slow. However, I tend to follow the best practices that I learned
from various FICO (!) consultants, who recommended against doing anything heavy
in the RHS, but rather getting back out of the rules engine ASAP and doing
those heavy tasks in the invoking application.
This approach works nicely, because the rules engine does what it's good at
(making decisions based on facts that are in working memory) and my Java
(Spring) app does what it's good at (getting data and integrating with other
systems).
The added benefit is that if I need to synchronise access to the session, it's
not such an issue if each request is back out of the rules engine in
microseconds.
Steve
On 17 Aug 2012, at 13:01, Wolfgang Laun <wolfgang.l...@gmail.com> wrote:
> On 17/08/2012, Stephen Masters <stephen.mast...@me.com> wrote:
>
>> But here are some slightly more practical thoughts from my experience...
>> Inserting new facts is slow. (although still sub-millisecond)
>> Evaluating rules is fast.
>
> Left hand sides of rules are evaluated while new facts are inserted,
> so the above distinction does not make sense for me. Perhaps you can
> explain what you mean by "evaluating rules"?
>
> Executing ("firing") rules depends on what's done on the right hand
> side, so you can't mean that.
>
> -W
> _______________________________________________
> rules-users mailing list
> rules-users@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
