Also, I should have mentioned that inserting increasing numbers of identical (!) facts against a single rule is not a realistic scenario, especially if the Engine is not permitted to work on it between insertions.
-W On 10 February 2012 16:40, zstlaw <[email protected]> wrote: > > laune wrote > > > > You realize that the modify negating part of the condition must result in > > an immediate retraction of the logical insertion? > > Yes. I did realize that the logical insert would retrigger. sorry, I had > started with logical inserts without that clause. I only added the > negation > portion when I wrote the manual insert test (i didn't include the manual > retract logic in my post either). Finally I changed to modify only > approach > for a huge speedup. (Modify was initially the trivial case I posted but > later I used wrapper objects and was able to mirror the complexity of the > other approaches without a comparable slowdown. I used the trivial modify > example since the final approach required a drastically different datamodel > and made the post rather long) > > > laune wrote > > During the runs: were there any other rules besides the one you have > > shown, > > especially rules with patterns using AnomalyFact or DataPoint? > > My original rule file had many more rules but the numbers collected were > for > performance testing with only a single rule once I identified that even the > simplest case was not scaling properly. So yes the rule file was only a > single rule (plus an additional retraction rule for the non-logical insert > test) the rule while useless on its own proved sufficient to show that > scaling to millions of datapoints was impossible using logical insertions > or > even manual insert/retract. Luckily I was able to restructure my data to > use a modify based processing model but was dismayed that logical insert > suggestion that was documented as preferable scaled so poorly. It made me > suspect that I was misusing some part of the system. > > But the case is simple to test. If performance is linear than doubling the > number of objects should result in double the time. Anything worse is not > scalable for an extremely busy systems. (thousands of points per second) > My > post was largely to determine if others had also reproduced simular scaling > issues. If so then we should modify the documentation to be more > appropriate in it's suggestions. > > -- > View this message in context: > http://drools.46999.n3.nabble.com/rules-users-Performance-scaling-with-fact-insertion-tp3727727p3732884.html > Sent from the Drools: User forum mailing list archive at Nabble.com. > _______________________________________________ > rules-users mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-users >
_______________________________________________ rules-users mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-users
