Advances in Rule Engine Performance

From the beginning, DecisionRules was designed to be a fast, scalable rule engine with solid performance. Over time, its evolution has brought a long list of new features and increased maturity—but also greater complexity. During that time, we mainly focused on preserving the core performance. Today, however, we face a different reality. With a growing and increasingly diverse customer base, we are encountering new challenges, with performance remaining a top priority. Simply maintaining the original performance is no longer enough—we must continue improving it.

Why Performance Matters

Each of our customers has unique use cases and requirements. For some, performance is not a major concern because their rules are relatively simple, they do not require fast response times, and their rule solves are infrequent. However, if even one of these conditions does not apply for you, there is a high chance you will eventually join the ever-growing group of customers for whom performance is a critical factor.

Addressing Key Challenges

The three conditions mentioned above translate into the three most common performance challenges. The first challenge is maintaining reasonable response times as the complexity of the business process increases. With twice as many rules within a process, it is unrealistic to expect response times to remain the same. However, with effective organization, the increase does not have to be linear. We address this challenge with our workflow feature, which enables optimal orchestration of business rules.

The second challenge is response time itself. Some applications have strict latency requirements, demanding to spare every millisecond. These cases are among the most challenging, as they require a delicate balance between infrastructure, application setup, and rule design. To facilitate more effective optimization, we developed new measurement tools that provide valuable insights into system performance. With these tools, we significantly accelerated rule execution for many of our customers.

The third challenge is scaling the application to reliably handle all incoming requests at all times. This is a common stumbling block for high-volume applications, but it is also one of our strengths—DecisionRules was built with scalability in its DNA. However, designing for scalability is one thing; maintaining it is another. It requires continuous attention, deep understanding of the software, container orchestration, and the underlying infrastructure.

Performance Testing and Results

Over the past six months, our technical team has conducted multiple rounds of performance testing and subsequent optimizations at various levels of the software. These efforts have spanned infrastructure setup, container orchestration, data caching, and the core business logic of the rule solver itself. The results are striking.

To illustrate, consider a sample decision process involving two sequential business rules, both decision tables. The first is a large table with 10,000 rows, while the second is a smaller table with only 30 rows. The process is easily set up within a main orchestration rule.

The orchestration rule

‍

Let us now subject the process to a brief performance test. We shall be calling the main rule over the period of 10 minutes while gradually increasing the number of virtual users from 1 to 30. To make the test more demanding, we will make batch calls, sending a set of 12 distinct inputs in every single call to the solver.

For comparison, we run the test on two versions: DecisionRules 1.18.4 and the more recent DecisionRules 1.19.5. To take full advantage of the new version, we used workflow as the main rule there instead of its predecessor, the rule flow. The results are shown in the plots below.

Test results for DecisionRules version 1.18.4

Test results for DecisionRules version 1.19.5

We are proud to report a significant improvement. In terms of response times, the newer version performed roughly five times faster than the older one. Accordingly, it was able to process approximately five times more requests. While these numbers may vary depending on the specific rules and test setup, the comparison clearly demonstrates our recent progress.

Looking Ahead

Improving performance amid growing software complexity is no easy task. We had to tackle all of the challenges outlined above. In many cases, the real-world demands of our customers pushed us to refine our system further. And we are certain that new challenges will arise in the future. After all, that highly complex application with a strict 10-millisecond response time requirement and extreme traffic is probably out there, waiting to get our attention.