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

[Wolfgang Laun]

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 at 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 at 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 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/20101115/58167314/attachment.html