Power-up your business rules

Performance of business rules is typically not the first thing to throw an eye on when managing business logic. With growing complexity of the business logic, the options of getting rules execution optimized increase as well.

First thing about performance is how to measure it. Visual Rules Business Rules Management System provides a function to track the entire execution of all business rules, including execution time. With this information it is fairly easy to find the hot spots of time consumption.

Rule Performance Hot Spot

Rule Performance Hot Spot

The trace starts right at the beginning of the first flow rule that is called. In this example there is obviously one element that consumes most of the execution time. As this is a flow rule call, there is the need to look into the detail rules that are called, but applying this approach will definitely help you find the actual consumer.

Of all the many projects I have analyzed so far, there are always similar reason patterns for low performance:

  • Calling external services
  • Database interactions within a loop
  • Overuse of collection functions

As all rules are executed sequentially, this may cause long processing time when rules are waiting for external services or database queries to be executed. Especially for database calls, you should always consider whether it might be useful to read all data first before starting rules processing. For an external service there could be an option to make an asynchronous call if you do not rely on any feedback for further rules execution. Collection functions are simply overused when results of those functions are not strictly reused or when they are processed multiple times within a loop.

The list of three contains the performance leaks that I see as having the largest influence. Of course there is some more minor improvement potential. Some examples:

  • Move those rule parts that are executed more often than others to the top of decisions
  • Reduce amount of parameters in flow rules; instead use more globally defined parameters
  • Use list of type map where you need items randomly

I recommend to focus on the 3 named improvement fields since any further “improving” might at the same time decrease readability of the flow rules. And having comprehensible rules ath hand is one of the major benefits of using a business rules system. Instead there is the technical side where improvements should be considered next. This means, e.g. changing the parameters of the system can be much more effective.

The technical / other side of the story

Which parameters do we have to look at when searching for improvement potential? First of all, there is the machine used for execution. Using Java means upgrading memory and CPU are worth considering. There are some major settings in Visual Rules Code Generator itself. (Now it is getting technical…)

  • Use call-by-reference instead of call-by-value
    This is not just simple setting as this will influence the business rules as well. If the model uses structured objects it is better to use call-by-reference right from the beginning.
  • Disable “rule statistic and listener code”
    This will skip additional code that is generated with each rule element. The more rule elements you have, the more time is needed – which, of course, is still true even if rule statistics is not being produced! The drawback is that you won´t have statistics but I have seen models running 3 times (!) faster – an often underestimated switch.
  • Prefer primitive Java types instead of wrapper types

With all these tips in place. the model should be fast enough – if not there are definitely external bottle necks. It is also reasonable to search for certain implementations that can be better done in Java. One example is to use a decision table as look-up for text translation. There are many good Java frameworks out there that do exactly the same a lot faster. However, in my eyes it´s not sufficient to solely go for performance. The business rules representation is used to keep things comprehensible and easy to change. Moving things into the Java code should not comprehend any business logic just to make it faster.

Which are your experiences with rules performance? I am curious to learn and discuss!

 

About the author

Mario Anders

Mario Anders

Since 2007 with Bosch Software Innovations I worked in several customer projects on different countries and continents. My experience in Visual Rules is gained mainly throughout projects in banking sector but also smaller projects for automobile industry, insurance and trading companies. I like it to travel to the different places which is really easy as consultant and project manager but also enjoy the area around the Lake Constance – especially the Alps – where Bosch SI is located.