[rules-users] Performance scaling with fact insertion

[Wolfgang Laun]

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 <zstlawre at akamai.com> 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
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20120210/10cd40f0/attachment.html