Also, the condition code >= 000000000052 && <= 000000000052, looks like the simpler code == 000000000052, to me. -W
2010/5/5 Edson Tirelli <ed.tire...@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 <dbrownel...@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@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@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