[rules-users] Bulk-Retract speed conundrum

[Edson Tirelli]

   Daniel,

   I think I missed your previous messages but can't you simply throw the
session away and create a new session for every claim (don't forget to call
dispose() when throwing away a session)?

   Also, your rule seems odd, so I am assuming that was just a sub-optimal
example. As it was pasted, it seems to me that it could be simplified to the
following, more efficient rule:

rule "RULE_2090"
when
       $cl: ClaimLine(historic == false, code == 000000003908, type == "T")
       $historic: ClaimLine(historic == true, type == "P", code >=
000000000052 && <=
000000000052, $dt : date, eval(Utilities.isWithinTimePeriod($dt, $cl.date,
"Y", "99")) )
then
       String ruleName = drools.getRule().getName();
       results.addMessage(ruleName, "000000003908","Only 1 test per day");
       results.setRefer("R");
end

   Inlining the eval helps a bit, and in your example rule the collect()
call is totally redundant as it will always be true and the consequence is
not using the bound list.

   Like in SQL queries, the performance of the rules is totally dependent on
how they are written and the how you modeled the domain model. Also, if you
have just a couple rules, it might be more efficient running pure java code,
but for higher number of rules, Drools becomes more and more efficient when
compared to simple java code implementations of the rules.

   I worked with a customer sometime ago that uses hundreds of rules with
500k+ facts in memory constantly and has average response time on the 100ms
order... although, they did fine tuned their rules.

    Edson

2010/5/5 djb <dbrownell83 at hotmail.com>

>
> Hi Drools aficionados,
>
> This is further to my request to improve speed.  As requested previously, I
> am providing an example rule.
>
> So, I found that by only retracting facts after processing multiple claims,
> instead of after every claim, I managed to improve speed from 300ms per
> claim to 50ms!  We need it to be sub-170ms to be a viable option.
>
> But, I need to retract facts.  As you can see, if I add new Claim data, it
> might match the last guy's claim data (Bad!).  It would appear that
> 'disabling' the data would require an update and take as much time as a
> retract.
>
> So, is there any way around this?  Am I stuck with 300ms per claim?  Would
> changing to sequential stateless session be possible, or worthwhile?  If I
> can't improve the speed, I will have to advice against Drools for the
> project.
>
> regards,
> Daniel
>
>
> ---------------------
> My rules look like this:
>
> rule "RULE_2090"
> when
>        $cl: ClaimLine(historic == false, code == 000000003908, type == "T")
>        $historic: ClaimLine(historic == true, code >= 000000000052 && <=
> 000000000052, type == "P", $dt : date)
>        eval(Utilities.isWithinTimePeriod($dt, $cl.date, "Y", "99"))
>        $historic_many: ArrayList(size >= 0) from collect(ClaimLine(historic
> ==
> true, code >= 000000000052 && <= 000000000052, type == "P"))
> then
>        String ruleName = drools.getRule().getName();
>        results.addMessage(ruleName, "000000003908","Only 1 test per day
> ");
>        results.setRefer("R");
> end
>
>
> --
> View this message in context:
> http://drools-java-rules-engine.46999.n3.nabble.com/Bulk-Retract-speed-conundrum-tp779188p779188.html
> Sent from the Drools - User mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>



-- 
 Edson Tirelli
 JBoss Drools Core Development
 JBoss by Red Hat @ www.jboss.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20100505/79ef943a/attachment.html