[rules-users] Drools STREAM Mode performance with rather simple rule

[Roess. Oliver]

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/			Bernd Seeburger, Axel Haas, Michael Kleeberg
Registered Office:
Edisonstrasse 1				Vorsitzender des Aufsichtsrats/Chairperson of
D-75015 Bretten				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 at seeburger.de		HRB 240708 Mannheim
_________________________________________________________________________

Dieses E-Mail ist nur fur den Empfanger bestimmt, an den es gerichtet 
ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes
Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungs-
au?erung ist die des Autors und stellt nicht notwendigerweise die
Sind Sie nicht der Empfanger, so haben Sie diese E-Mail irrtumlich
erhalten und jegliche Verwendung, Veroffentlichung, Weiterleitung,
Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt.
Weder die  noch der Absender (Oliver Roess)
ubernehmen die Haftung fur Viren; es obliegt Ihrer Verantwortung,
die E-Mail und deren Anhange (0) auf Viren zu prufen.

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
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.
_________________________________________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20101115/e2b11d63/attachment.html