Here at Auster Solutions, we have been working with Drools since its version 2.0, back in 2004. We were developing a product for Telecom Rating & Billing data processing and selected Drools for its rules processing module. Now that our product is out there and running Drools 4 for some time, it is time to give some feedback to the project.
Here in Brazil, especially inside big companies, we usually have a hard time to use or embed open source software, probably due to lack of support and formality they suffered years ago. On the other hand, since Drools was already demonstrating high technical quality, increasing adoption and constant evolution, it has turned out to be regarded as a serious open source tool, which eventually enabled its adoption inside our solution.
Now let me go through the technical info. Inside our rules processing module, the unit of work is called request. Several requests might be processed at the same time, within multiple threads.
Each working memory contains the facts related to a single request (actually we do it twice, but it will be explained later on). The size of the requests varies widely, so we can find tiny requests that generate less than a dozen facts, as well as we can have tens of thousands of facts being asserted from a single, yet very large, request. Just out of curiosity, the largest requests might even exceed 100,000 facts.
We have collected some data from one of our customer’s production environment. The table below divides requests into 5 differently-sized groups and presents the average amount of facts and processing time for each request. The solution consists of about 300 rules, running on a Fujitsu pw650 server with 8 CPUs, 16GB memory, Solaris 10, Java SE 5, and Drools 4.
| Avg # of Facts | Avg. Processing Time | |
|---|---|---|
| Smallest | 9 | 0.3s |
| Small | 115 | 0.4s |
| Mid-size | 580 | 0.7s |
| Large | 6100 | 3.9s |
| Largest | 36000 | 22.6s |
| Overall Avg | 733 | 0.8s |
Please note that, in an attempt to evaluate the tool by itself, both the application startup and I/O operations (file and DB access), which represents about 90% of the whole processing time, have been ignored, i.e., we have considered exclusively the time it took to allocate a working memory, set the globals, assert the facts (LHS), fire all rules (RHS), and dispose the session.
Now let me go back to explain the two-working-memory-per-request issue. The process for each request can be roughly divided in two steps: enrichment and validation. Enrichment consists of rules that basically add data to the facts in the working memory, in order to enrich them, while validation is the main processing phase that generates the final results of the processing.
At first, the implementation of the rules processing module had a single stateful working memory for each request and the rule base had all enrichment and validation rules together. Enrichment rules had, of course, a higher salience than the validation ones.
Some time later, while trying to improve the rules processing performance, we noticed that it would be faster if we created two working memories for each request, one (stateless) for enrichment, and other (stateful) for validation.
We found out that the overhead of allocating a working memory and asserting all facts twice was largely superseded by the fact that each update executed during enrichment step would no longer affect the agenda. Another important detail is that the actual performance gain was due to the sequential mode, which is available only on a stateless session.
Before we finish this article, we would like to illustrate the magnitude of the rules processing our system has performed so far only for one of our customers: more than 16 million requests have been processed during the past 4 years. Just last month, the application processed up to 390,000 requests, comprising nearly 200,000,000 facts evaluated by Drools.
In the final analysis, despite a few obstacles we have found along the way, Drools is working very well. We were able to achieve a good development throughput and short maintenance turnaround, a relatively short learning curve, and a fairly acceptable performance.
————-
Luciano Morozowski Junior is a software architect at Auster Solutions. He has been working with application performance improvement since 2006 and specializing in Drools for more than one year now.
Auster Solutions is a Brazilian software company focused on the Telecom Industry, specially on the OSS & BSS processes chain. Auster has been running Drools inside its products since 2005.
