[rules-users] Bulk-Retract speed conundrum

Wolfgang Laun wolfgang.laun at gmail.com
Wed May 5 13:10:20 EDT 2010


Also, the condition
   code >= 000000000052 && <= 000000000052,
looks like the simpler
   code == 000000000052,
to me.
-W


2010/5/5 Edson Tirelli <ed.tirelli at gmail.com>:
>
>    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
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>




More information about the rules-users mailing list