[rules-users] Drools Fusion Performance and RETE algorithm

Edson Tirelli tirelli at post.com
Tue Aug 17 15:55:04 EDT 2010


    Hi Orlando, Mauricio,

    While the goal of the whole Drools platform is to provide a seamless
environment for users to model business behavior using rules, processes and
events, it is a misconception to say that it is all executed on RETE.
Besides implementing several optimizations on top of the classic RETE
algorithm (as designed by Dr. Forgy back in the 70's), Drools has specific
algorithms to which it delegates processing of specific use cases/features
(read some fusion and flow features).

    Regarding your question, entry-points are partitions on the RETE network
that allow for parts of it to be evaluated concurrently, besides creating
separate "name spaces" for facts (scopes if you will). So it does help on
reducing the overall load of the matching algorithm. Although, rules are
still fired sequentially as to ensure consistency of the working memory.

    Regarding use cases, we have customers that use 24x7 stateful sessions,
keeping over 1M facts in memory constantly, with new facts coming into the
session and facts expiring from the session all the time. The throughput of
such use cases is obviously dependent on the percentage of facts/rules
matchings, so it is hard to foresee what you will achieve on your use case
without knowing in detail your rules.

    Although, the chosen architecture for your kbase and sessions will
obviously have a high impact on the performance metrics you will achieve.
Since you mentioned that in your use case every single fact will match and
cause rules to fire, and the actions involve heavy operations like database
access, I would recommend looking into an "agent" architecture, where you
partition your knowledge base into several kbases with related rules. The
kbases will operate on the atomic (or "raw") events and create the composite
events that you can feed into entry points of sessions of subsequent kbases,
effectively increasing the overall system throughput and simplifying the
maintenance of each agent's kbase in particular.

    If you are used to CEP nomenclature, you know that the above is a
simplified description of an EPN.

    Finally, you asked about the difference between regular facts and
events, and basically all events are facts with special "properties". These
properties allow the engine to do some fancy stuff with them, like the use
of sliding windows or event lifecycle management (i.e., automatically
expiring events). Although, there is nothing wrong in modeling events like
regular facts if that best fits your design.

    Hope the above helps,
        Edson

2010/8/17 Orlando Costa <orlandoricardo at gmail.com>

>
> Thanks, I already have seen this some days ago:
> http://www.redhat.com/f/pdf/jbw/amollenkopf_430_applying_drools.pdf
>
> but it does not say the amount of events coming, and the internals are more
> about the whole solution itself than about the internal Drools
> Expert/Fusion
> architecture (though is shows good rules examples with Fusion use of
> course).
> Br
> Orlando.
>
> --
> View this message in context:
> http://drools-java-rules-engine.46999.n3.nabble.com/Drools-Fusion-Performance-and-RETE-algorithm-tp1190098p1193090.html
> Sent from the Drools - User mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>



-- 
  Edson Tirelli
  JBoss Drools Core Development
  JBoss by Red Hat @ www.jboss.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20100817/a16f40f1/attachment.html 


More information about the rules-users mailing list