tag:blogger.com,1999:blog-5869426.post7724683463647431666..comments2024-03-25T09:15:58.430+00:00Comments on Drools & jBPM: Drools vs JRules Performance and Future R&DMark Proctorhttp://www.blogger.com/profile/03304277188725220501noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-5869426.post-46479683352009497362021-04-14T08:08:15.442+01:002021-04-14T08:08:15.442+01:00Mua vé máy bay tại Aivivu, tham khảo
mua ve may b...Mua vé máy bay tại Aivivu, tham khảo<br /><br /><a href="https://aivivu.com/ve-may-bay-di-my-us-gia-re-bao-nhieu-tien/" rel="nofollow">mua ve may bay di my</a><br /><br /><a href="https://aivivu.com/ve-may-bay-di-hcm-sai-gon-bao-nhieu-tien/" rel="nofollow">vé máy bay vietnam airline đi hồ chí minh</a><br /><br /><a href="https://aivivu.com/ve-may-bay-di-ha-noi-han-bao-nhieu-tien/" rel="nofollow">giá vé máy bay chu lai hà nội</a><br /><br /><a href="https://aivivu.com/ve-may-bay-di-da-lat-dli-bao-nhieu-tien/" rel="nofollow">giá vé máy bay hà nội đà lạt khứ hồi</a><br /><br /><a href="https://aivivu.com/ve-may-bay-tu-my-ve-viet-nam-gia-re/" rel="nofollow">mua vé về việt nam</a><br /><br /><a href="https://aivivu.com/dich-vu-xe-dua-don-taxi-san-bay-noi-bai-gia-re/" rel="nofollow">xe đưa rước sân bay</a><br /><br /><a href="https://aivivu.com/combo-ve-may-bay-khach-san-gia-re/combo-du-lich-quy-nhon/" rel="nofollow">Combo Quy Nhơn</a>vé máy bay từ canada về Việt Namhttps://aivivu.com/ve-may-bay-tu-canada-ve-viet-nam-gia-re/noreply@blogger.comtag:blogger.com,1999:blog-5869426.post-36901231078789798002010-10-12T21:50:58.925+01:002010-10-12T21:50:58.925+01:00Performance also needs to be designed into your BR...Performance also needs to be designed into your BRMS integration solutions. i.e. If your data fetch routines are taking two seconds, the 30 millis it takes to execute a rule won't matter in the grander scheme of things. Likewise - if you write a rule that needs to evaluate too many possibilities it may never finish executing.<br /><br />Nigel DeFreitasAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-5869426.post-90606155136589162372008-09-19T15:45:00.000+01:002008-09-19T15:45:00.000+01:00We don't tend to do support in the forums. Please ...We don't tend to do support in the forums. Please use the user mailing list, or you can get direct priority support from sales@jboss.com<BR/><BR/><A HREF="http://www.jboss.org/drools/lists.html" REL="nofollow">http://www.jboss.org/drools/lists.html</A>Mark Proctorhttps://www.blogger.com/profile/03304277188725220501noreply@blogger.comtag:blogger.com,1999:blog-5869426.post-18223565365906305012008-09-19T11:48:00.000+01:002008-09-19T11:48:00.000+01:00Mark we are using Drools 4.0.3 for our sales appli...Mark we are using Drools 4.0.3 for our sales application which is an Eclipse RCP based application. We are having around 10000-15000 rules to be loaded as part of this application. Currently we have tested the application with around 2000 rules. When we create a package and save it in a file, the file size goes nearly in the range of 25-26 MB. Can you suggest any way to optimize the size of the package since we want to scale upto 10000-15000 rules?<BR/>Since this is an RCP application which is going to run in an offline mode (by sales guys) it is very important for us to reduce the loading time of these rules. Appreciate if you provide us some suggestion.Ashish Rhttps://www.blogger.com/profile/07118467961319697920noreply@blogger.comtag:blogger.com,1999:blog-5869426.post-50857571890455174442008-06-26T21:45:00.000+01:002008-06-26T21:45:00.000+01:00Here is the rule set Haley used:(deftemplate guest...Here is the rule set Haley used:<BR/><BR/>(deftemplate guest<BR/> (field name)<BR/> (field sex)<BR/> (field hobby)<BR/> )<BR/>(deftemplate seating<BR/> (field number-assigned)<BR/> (multi-field assignments)<BR/> )<BR/>(defrule AssignFirstTwoSeats<BR/> (declare (salience -3))<BR/> (guest (name ?guest1) (sex ?sex) (hobby ?hobby))<BR/> (guest (name ?guest2) (sex ~?sex) (hobby ?hobby))<BR/> =><BR/> (assert (seating (number-assigned 2) (assignments ?guest2 ?guest1)))<BR/> )<BR/>(defrule AssignNextSeat<BR/> (declare (salience 0))<BR/> (guest (name ?guest1) (sex ?sex) (hobby ?hobby))<BR/> (guest (name ?guest2) (sex ~?sex) (hobby ?hobby))<BR/> (seating (number-assigned ?n) (assignments $?others ?guest1&~:(member ?guest2 ?others)))<BR/> =><BR/> (assert (seating (number-assigned =(+ ?n 1)) (assignments $?others ?guest1 ?guest2)))<BR/> )<BR/>(defrule AbandonAssignment<BR/> (declare (salience -2))<BR/> ?f <- (seating)<BR/> =><BR/> (retract ?f)<BR/> )<BR/>(defrule FoundSolution<BR/> (declare (salience 1))<BR/> ?f <- (seating (numer-assigned 16) (assignments $?assignments))<BR/> =><BR/> (printout t "Seatassignments: " $?assignments t)<BR/> (halt)<BR/> )<BR/><BR/>As you can see, it bears no resemblance at all to Miranker's benchmark. As we all know, Daniel Miranker went out of his way to write the most inefficient rule set he could think up! He wanted to create a small, easily implementable rule set that would generate huge amounts of work. By contrast, Haley's rule set solves the same problem (seating arrangements) using a well optimised, efficient rule set. Hence, the comparison they do (with JRules, showing approx 15 seconds against Haley's .44 second for 128 guests) is totally meaningless. I would hope that this represents a genuine mistake on the part of Haley, and not a deliberate attempt to mislead.Charles Younghttps://www.blogger.com/profile/00294796587334375598noreply@blogger.comtag:blogger.com,1999:blog-5869426.post-47103145174979799832008-05-26T10:55:00.000+01:002008-05-26T10:55:00.000+01:00Greetings:It's been a while since I read this back...Greetings:<BR/><BR/>It's been a while since I read this back in my Fair Isaac days. However, I do feel that reporting fantastic results for any kind of benchmark does require that the benchmark be repeatable - meaning that both data and rules must be published so that this can be checked by other, more independent verification organizations. Like, well, you know, KBSC or someone like that. :-)<BR/><BR/>Seriously, Haley used to publish incredibly wild benchmark results for Miss Manners but they would NOT allow anyone to see the code nor to use their tools and/or code to double check the results.<BR/><BR/>I do believe that the client reported exactly what Mark says. However, before Mark publishes something as wild as this he should allow someone to double check the client's work. Almost any set of rules will run one way with one rulebase and another with another rulebase and then completely change 180 degrees when the rules are restructured to favor the other vendor.<BR/><BR/>IMHO<BR/><BR/>SDGJames Owenhttps://www.blogger.com/profile/05324939968003160212noreply@blogger.comtag:blogger.com,1999:blog-5869426.post-57938620758261437472007-11-22T15:07:00.000+00:002007-11-22T15:07:00.000+00:00I'm curious to see the rules for JRules. If your a...I'm curious to see the rules for JRules. If your anonymous poster would like some free JRules performance analysis they can contact me on dselman-at-ilog-dot-fr.<BR/><BR/>Daniel Selman<BR/>http://blogs.ilog.com/brms/author/dselman/Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5869426.post-4433201501435926172007-08-31T21:48:00.000+01:002007-08-31T21:48:00.000+01:00From my own experiments with alpha node re-orderin...From my own experiments with alpha node re-ordering the gains for 10K, and 20K rules with 5, 10, 15, 20, 25 alpha nodes per rule was less than 5%.<BR/><BR/>the way I tested it was to generate 3 different sets of rules. the first had the conditions in most inefficient order. The second in optimal order. The third in random order.<BR/><BR/>Collapsing the alpha nodes has been done before in previous research. For most cases it probably won't help. AFAIK, the only cases where it would help is with 50K+ rules that have no joins, dozens of conditions (aka alpha nodes) and large dataset over 100K rows.<BR/><BR/>In my experiments, I tried 100K, 200K, 300K, 500K and 1million rows of data. In the case of 1million rows, the memory delta was still less than 5%.<BR/><BR/>disconnecting parts of the network should provide a significant boost. The trick will be the efficiency of disconnecting and reconnecting the module. You're probably better off organizing the rules into multiple rulesets, then load each ruleset into a different engine. It's manual partitioning of the rules, but it has proven to be very effective.<BR/><BR/>RETE analysis is probably the most bang for the buck in terms of time invested versus benefit. With good analysis, the tool can suggest ways of partitioning a large ruleset into smaller ones. With rule flows, that has a great potential. The best example I can think of is when the process splits/forks.<BR/><BR/>the easiest way to do a lazy latch, is to just convert the join to a query. there's some literature on this, but I can't remember the paper at the moment. I've used the technique and so have the old timers from Inference and ART.woolfelhttps://www.blogger.com/profile/13814445471254728002noreply@blogger.com