I recently submitted a solution to the Decision Management Community Benchmark Challenge. The benchmark comprises a single, large decision table of 16,369 rules for various combinations of medical service characteristics used in the Condition columns. There are 7 input columns and 3 output columns.
My solution comprised the Camunda DMN engine embedded in an AWS Lambda function with no special tuning, just using out of the box configuration. For those interested in DMN performance, the results may be of interest…
Did we loose any performance if we define rules for example 100K rules for complex scenario.
I would suggest that as a general rule of thumb, the more rules in a DMN table, the more computation time required, but there are lots of factors such as the hit policy, sparseness and frequency of actual use cases etc. In my example I found that 1600 rules resulted in an average execution time of 71ms, 16,000 rules (ie 10 times scale) resulted in an average of 235ms (220 if I tune the JVM memory a little)…
In general I tend to recommend use of DMN for human managed business rules (eg credit decision rules) and thus the rule size is typically in the 10’s possibly 100’s. In the case of a pure lookup table, I would argue an in memory database index would likely be a faster solution.
For really large business rule sets, there are additional tactics which could be used to improve efficiency and manageability. The rules etc may be amenable to structured decomposition and chained together as a sequence of smaller decisions etc…
I should also point out that this was interesting from the point of view of how fast the raw DMN engine is and that the choice to use DMN should take into account not just performance, but many considerations such as skillset, maintainability etc. If I need more performance, then these kinds of lookup tables are candidates for cached responses. Hence with the AWS lambda approach I can add a cache with 3 clicks or less. In this case the performance drops to a few (34) milliseconds…