[rules-users] Is RETE algo optimizes the performance in a stateless session.

[Michael Anstis]

In short no.

Activations are determined when Facts are inserted into WorkingMemory not
when a call to fire the rules is made. Consequentially, IMO, "through put"
is really limited to how quickly you can insert Facts into the network. You
could have multiple threads inserting Facts into different stateless
sessions however you'd need to decide how to partition your facts between
Threads.

Perhaps you should trial your performance concerns before embarking on more
elaborate architectures? If your processing is stateless than you will be
able to scale this horizontally if the need arises.

With kind regards,

Mike

2010/9/27 Harshit Bapna <hrbapna at gmail.com>

> Hi All,
>
> Thanks to Leo and Mark for the help...
> Please find my comments(blue) inline.
>
> Crisp question:
> *Is there any functionality in drools where I can run the rules(stateless
> session) in parallel threads to increase the throughput ?*
> Note: The rules actions won't change the facts/data such that it would
> require running of the rules again. Hence I came to this conclusion that
> stateless sessions are required.
>
> 2010/9/24 Leonardo Gomes <leonardo.f.gomes at gmail.com>
>
>> Hello Harshit / Mark,
>>
>> My reasoning behind the yes, is that:
>>
>> - If you have 10 rules that won't necessarily always match, it's better to
>> use Rete, than sequentially match one-by-one. The tree structure with the
>> sharing of nodes for different rules seems to always be a better approach
>> for me, than sequentially testing one-by-one and, in some cases, retesting
>> the same condition on different rules (if that happens);
>>
>> In my use case, the overlap of sub-conditions is not much. There would be
> only few conditions which will have common sub conditions and the no of sub
> conditions would be max 5.
> After reading the articles, I agree with Leo that still its better to use
> RETE than sequentially testing one by one.
>
> Also the rules actions won't change the facts/data such that it would
> require running of the rules again. Hence I came to this conclusion that
> stateless sessions are required.
>
> I have jotted down the applicable reasons for me to use the rule engine
> (based on my readings on drools & rete) :
> 1. separation of business logic from application logic.
> 2. rules are flexible and likely to be changed overtime.
>
> My requirements would be satisfied by using stateless session functionality
> of drools.
> Questions:
> *Is there any functionality in drools where I can run the rules in
> parallel thread to increase the throughput ?*
> (I can use java threads to run the rules separately in different threads
> but would like to know if there is any optimization approach in drools for
> stateless sessions)
>
> - You can write if-then-elses in a imperative language and perform better
>> than Rete, but if your rules are complicated and you have many of them, it's
>> likely that rete can do a better job; Also, if you need to change your rules
>> or add new ones, it will be easier to do that declaratively;
>>
>> I think here you are suggesting that using a rule engine would be better.
> (based on ur comments on the need to change rules, add new ones)
>
> I first put the links, because you can use that to judge yourself whether
>> or not you might gain in performance in your own scenarios, with that
>> material.
>>
>> Thanks Leo. It really helped me to improve my understanding of the
> algorithm.
>
>>
>> @Mark:
>>
>> In general a stateless session is just a convenience api for stateful, it
>>> just wraps. So no performance gain at all.
>>
>>
>> I think here you're saying that there will be no performance gain compared
>> to a stateful session, but I believe that the question was more on the lines
>> of "I know that with a stateful it's efficient, how about stateless". I
>> tried to say that, yes, it's also worth using Rete in stateless scenarios.
>>
>>  Mark, I meant the same what Leo explained.
>
> Cheers,
>> Leo.
>>
>> 2010/9/24 Mark Proctor <mproctor at codehaus.org>
>>
>>  On 24/09/2010 16:18, Leonardo Gomes wrote:
>>>
>>> Have a look here: http://www.drdobbs.com/184405218
>>>
>>> here: http://blog.athico.com/2007/07/sequential-rete.html
>>>
>>> and here: http://herzberg.ca.sandia.gov/guidelines.shtml
>>>
>>> The easy answer for your question is "Yes" ;-)
>>>
>>> It depends :)
>>>
>>> In general a stateless session is just a convenience api for stateful, it
>>> just wraps. So no performance gain at all.
>>>
>>> There is a "sequential" mode, but in all honest you won't get any
>>> measurable perf gain. So I wouldn't use sequential mode for performance, the
>>> only reason to use it is if you want your rules to execute sequentially.
>>>
>>> Mark
>>>
>>>
>>> Cheers,
>>> Leo.
>>>
>>>  2010/9/24 Harshit Bapna <hrbapna at gmail.com>
>>>
>>>> Hi All,
>>>>
>>>> In a scenario where lets say 10 rule are to be fired (in any order) in a
>>>> stateless session than will I get the benefits of RETE algorithm (i.e
>>>> increased performance).
>>>> i.e Whether the engine will fire all the ten results in a parallel
>>>> fashion or Whether the engine will file each rule one by one.
>>>>
>>>> How RETE algorithm will improve the performance of the engine for rules
>>>> fired in stateless session ?
>>>>
>>>>
>>>> _______________________________________________
>>>> rules-users mailing list
>>>> rules-users at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>>
>>>>
>>>
>>> _______________________________________________
>>> rules-users mailing listrules-users at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users
>>>
>>>
>>>
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>
>
> --
> -- Harshit Bapna
>
>
> _______________________________________________
> 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/20100927/44666907/attachment.html