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