我们一直在寻求改善Drools DMN开源引擎的性能。 我们最近审查了DMN用例，其中输入数据节点的实际输入总体有所不同。 这突出显示了引擎的次佳性能，我们在最新版本中对此进行了改进。 我想分享我们的发现！

基准制定

当我们开始为该用例运行一个支持基准测试时，尤其是在调查具有稀疏填充的输入数据节点的大型DMN模型的场景时，我们注意到了一些奇怪的结果：火焰记录仪数据突出显示了记录消息时的性能严重下降，这非常消耗与应用逻辑本身相比，花费了大量时间。

该火焰图特别强调了测井框架人为地引起的堆栈跟踪合成消耗了大量时间。 在这种情况下，纠正措施是调整日志记录配置以避免此问题。 具体来说，我们禁用了日志记录框架的一项功能，该功能在调试活动期间非常方便，从而可以快速定位原始的调用类和方法：不幸的是，此功能的代价是合成堆栈跟踪，该跟踪最初污染了基准测试结果。 从这里学到的教训：请始终先检查非功能性需求是否真的掩盖了真正的问题！

在继续更详细地研究用例之前，这是必要且可行的步骤。

改善表现

继续并专注于DMN优化，我们专门开发了一个通用性很强的基准，同时也重点介绍了已提供给我们的用例。 该基准包含一个DMN模型，其中包含许多要评估的决策节点（500个）。 另一个参数控制输入数据节点的稀疏性以进行评估； 范围从值1（填充所有输入）到值2（仅填充两个输入中的一个），等等。

事实证明，该特定基准是突出一些潜在改进的非常有用的工具。

将比较基准设置为Drools 7.23.0版。最终，使用DROOLS-4204实现的第一个优化专注于在评估FEEL表达式的同时改善上下文处理，并证明可提供约3倍的改进，而使用DROOLS-4266进行的进一步优化则专注于特定决策表输入子句的用例表明，在DROOLS-4204的基础上，附加的〜2倍改进。

我们还在下图中收集了这些度量。

该图突出显示了当稀疏因子等于1时（填充所有输入时）的复合改进。 这是一个非常重要的结果，因为实际上它确实代表了原始用例中的主要 “快乐路径”场景。

换句话说，与在相同的用例上运行相比，我们实现了约6倍的改进

7.23.0。最终版 我在这里学到的教训是，在可能的情况下，始终努力争取这些复合的改进，因为它们确实可以彼此叠加，以获得更大的效果！

为了完整起见，我们使用以下度量重复分析，其稀疏因子等于2（实际上每2个输入填充1个）和50个（实际上每50个输入填充1个），并进行以下测量：

结果表明，对于等于2的稀疏因子，优化也很重要，但是随着该因子的增加，相关的改进并不明显-这是可以预期的，因为决策节点评估对整体执行逻辑的影响现在变得不那么重要了。

为了完整起见，还对包含多个规则行的单个决策表使用了另一个已经存在的基准进行分析：

结果表明，这些代码更改从整体上来看仍然可以提供相关的改进； 虽然显然不相同幅度为原来使用-情况。 这是另一项重要检查，以确保这些改进不适合特定用例。

结论

以Drools版本7.23.0.Final为基准，以及包含DMN模型和许多待评估决策节点的参考基准，我们实施了多项优化，这些优化一旦结合在一起，就可以使该特定项目的总速度提高约6倍用例！

我希望这是一篇有趣的文章，以强调要取得更好性能的一些方面； 让我们知道您的想法和反馈。

今天，您已经可以从Drools最新版本中的Kie DMN开源引擎改进中受益！

翻译自: https://www.javacodegeeks.com/2019/08/drools-dmn-performance-improvements.html