What and how are you timing?
Executing exactly this rule on three event types with just an int id,
running with
long t0 = System.currentTimeMillis();
int count = 50;
for( int i = 1; i < count; i++ ){
session.insert( new EventA( i ) );
session.insert( new EventB( i ) );
session.insert( new EventC( i ) );
}
session.fireAllRules();
long t1 = System.currentTimeMillis();
System.out.println( "execution of " + count + " triples: " +
(double)(t1-t0)/1000.0 );
I get on a (not-too-hot) laptop (Linux, Eclipse)
execution of 10 triples: 0.020
execution of 20 triples: 0.023
execution of 30 triples: 0.026
execution of 40 triples: 0.026
which is what I'd expect.
- With a String id, add about 0.005s
- With fireAllRules in the loop, add another 0.015s
With fireUntilHalt issued from another thread, timing is trickier, so please
explain this in detail.
-W
2010/11/15 Roess. Oliver <o.roess(a)seeburger.de>
Hello everyone.
I’ve got a question regarding the performance of Drools in STREAM mode. It
seems to me, that either Drools is not very fast here, or the problem is
with the rule itself.
This is the rule.
rule "ABC”
no-loop
when
$a : Aevent()
$b : Bevent(id == $a.id)
$c : Cevent(id == $a.id)
then
retract($c);
retract($a);
retract($b);
…(actions)
end
It basically says: act upon every group of A, B and C events with the same
ids. The retract statements will make sure, none of these events will get
matched again by this rule. Side question: is there any possibility to do
this rule without the retractions?
Regarding the performance:
If I put the arriving events in this sequence: A(x), B(x), C(x) where x is
the number of events being sent. No other events than A, B and C with the
same id being sent. And I repeat this sequence a small number of runs (12
times in a row), then it will take Drools:
For x=8, on average 3 seconds to detect all 96 patterns,
for x=16, on average 30 seconds to detect all 192 patterns.
But the average is not very meaningful. Sometimes the Engine does it in
(x=16) 10 seconds, and sometimes it takes him over a minute to detect
everything, sometimes it takes him nearly forever for no reason. We tested
this on different machines and we cannot predict a “stable” behaviour. We
figured out, that this instability might come from fireUntilHalt, which we
invoke from a separate thread. Some ABC groups get detected faster than
others and the total duration is totally variable as stated before.
When calling fireAllRules upon every insert, the total duration is stable
(4,5 sec for x=16 and 12 runs) and also the detection time for every ABC
group seems to be even.
So a few questions: whats the problem with fireUntilHalt? Are we using it
the wrong way? If fireAllRules is used after every insert, can rules be
triggered by actions of other rules? For event stream processing a solution
that fires almost always is desirable.
Why is the overall performance so poor? If I do x=32 and do just one run,
which means just a total of 32*3= 96 events being sent and it takes him 2,6
seconds to detect all 32 patterns. That’s not very fast, is it?
I’m using Drools 5.1.1 and the latest JDK.
It would be nice to get some opinions.
Best regards,
Oliver
*SEEBURGER AG* Vorstand/Seeburger Executive Board: Sitz der
Gesellschaft/Registered Office: Bernd Seeburger, Axel Haas, Michael
Kleeberg Edisonstr. 1 D-75015 Bretten Vorsitzender des
Aufsichtsrats/Chairperson of the Seeburger Supervisory Board: Tel.: 07252
/ 96 - 0 Dr. Franz Scherer Fax: 07252 / 96 - 2222 Internet:
http://www.seeburger.de Registergericht/Commercial Register: e-mail:
info(a)seeburger.de HRB 240708 Mannheim
Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist
und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material
enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die
des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der
dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich
erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift
oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die noch
der Absender (Oliver Roess) übernehmen die Haftung für Viren; es obliegt
Ihrer Verantwortung, die E-Mail und deren Anhänge (0) auf Viren zu prüfen.
The present email addresses only the addressee which it targets and may
contain confidential material that may be protected by the professional
secret. The opinions reflected herein are not necessarily the one of the .
If you are not the addressee, you have accidentally got this email and are
not enabled to use, publish, forward, copy or print it in any way. Neither
the , nor the sender (Oliver Roess) are liable for viruses, being your own
responsibility to check this email and its attachments (0) for this purpose.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users