我們一直在尋求改善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

總結

以上是生活随笔為你收集整理的Drools DMN最新开源引擎性能改进的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。