Drools 性能评估

Question

我想执行一个有状态/无状态的 drool 会话？假设 Spring Boot 默认线程池大小。我该如何考虑服务器处理能力？

规则很简单：

when
 Apple( color == red )
then
 System.out.println("hello");
end

规则引擎每秒可以支持的最大调用次数是多少？我如何进行计算？

Answer 1

这取决于太多因素，无法具体地说“每个 Y 规则需要 X 资源”。是的，规则计数（在某种程度上）很重要，但其他事情也很重要。我一直做的，也建议你做的，就是分配你认为合理的负载，对你认为的峰值负载进行压力测试——然后将其加倍（或其他合理的倍数）。发送并发要求。发送复杂的数据。发送简单数据。发送看起来实际上合法的数据。确保您的日志记录解决方案（如果相关）不会影响您的规则执行。一旦观察到该行为，您就可以调整生产配置。

一般来说，您将通过以下方式查看资源使用情况：

1. 工作记忆。当您将对象传递到规则引擎中执行时，这些对象将被序列化，然后反序列化。这是堆的主要使用者——传递到规则中的序列化/反序列化对象。请注意，如果您有创建新对象并将它们添加到内存的规则 - 这些也会增加您的堆使用量。
   
   我明确提到了序列化/反序列化，因为您应该确认您的对象确实干净且正确地序列化/反序列化。我曾经参与过一个项目，我们有一个对象要传递到 Drools 中，该对象大约 20kb，但序列化后爆炸到接近 1.2mb。我们无法弄清楚为什么当我们传入如此少的数据时我们总是会耗尽内存，但最终我们意识到这不是数据的问题，而是我们使用的结构序列化不佳。

2. 重新评估和循环。规则执行需要CPU。这似乎是显而易见的，但有一些特定的 Drools 工作流程会增加他的 CPU 使用率。如果您调用modify、update、 或insert，这会导致规则部分或全部重新评估。因此，如果您的规则在执行一次时消耗 X 量的 CPU，但有包含这些特定调用的规则，那么 X 是不够的，因为一次执行可能会产生多个其他执行。
   
   记住这一点很重要，因为 CPU 是规则执行中无限循环的主要指标之一（以及死线程）。如果您看到 CPU 突然激增并且它被固定在那里（并且该线程变得无响应），则表明您可能以输入对象刚刚触发无限循环的方式设计规则 - 例如。规则 A 触发并更新数据，以便规则 B 触发并更新数据，以便规则 A 触发，依此类推。
   
   另一方面，如果您定期看到 CPU 峰值回落，则表明您的规则传递了复杂数据，因此规则引擎需要花费大量“精力”来进行计算。输入可能会触发大量规则，或进行大量更新/修改。
   
   如果您发现您的规则“慢”，则它们很可能没有足够的 CPU。

这些是资源的基本持续使用。也就是说，当您拥有服务器时，会加载规则，并且您正在处理请求并将它们传入/传出规则，这通常是您将资源消耗归因于的地方。

然而，还需要考虑的是，Drools 执行的一些与框架相关的任务存在一次性*命中。

• 从文件系统读取时，读取和编译规则通常会产生 I/O，或者在远程检索规则时需要考虑网络延迟。规则被读入内存（消耗堆），然后进行处理、验证和编译（消耗 CPU）。
• 内存中的规则会消耗少量的堆。它们是经过编译的，因此它们消耗的量少于解析它们的文本，但它仍然是消耗量。

我曾经维护一个具有 48,000 个规则（大概）的微系统，每秒处理大约 15 个请求，分配使用 16 GB 内存和 4 GB CPU。这些规则从未改变工作记忆中的数据——这是一个简单的传递。然而，在启动时加载这些规则确实需要大约 10 分钟。（我会注意到，虽然这是一个 Spring 应用程序，但它是 Spring 2。对我来说没有启动。:( ...)

相反，我很不幸地也在开发一个包含大约 1000 条规则的应用程序。这个庞然大物的应用程序占用了超过 120 GB 的堆和（我上次参与的）大约 64 GB 的 CPU。这些规则非常古老（10 年左右）并且不断调用update（从顶部重新评估所有内容；这相当于使用工作记忆中的更新信息第二次调用规则......另一种选择是insert仅使用部分重新评估。）这些规则还通过复杂数据结构中的大量数据（其中大部分是不必要的）传递。有时，该应用程序会消耗其大部分或全部资源，并由于无法处理负载而减慢至几乎无响应。有时我被叫去识别由“更新”调用引起的循环规则。

基本上我想说的是，所需的资源取决于应用程序的特征和规则本身的实现。确定适当分配的最佳方法是执行压力测试来确定您的初始应用程序，然后进行监控。密切关注您的交易量 - 随着您的成长并拥有更多客户或服务更多请求，您将需要增加分配或重做压力测试，以确保您始终有足够的资源来处理峰值，然后再进行一些处理。

如果您提倡良好的规则设计（最大限度地减少对更新的调用等）并确保仅将数据传递到实际需要的规则中，则通常可以以相对温和的斜率以线性方式随负载扩展资源消耗。不幸的是，由于变量太多，“每个 Y 规则 X 资源”并不是真正可能的事情之一。

* -- 我说“一次”是指加载规则之类的事情，但实际上每次加载一次。如果您在应用程序启动时加载规则，那么它就是一次性的。但是，如果您在规则更改后或定期或以其他方式重新加载规则，则必须在这些时间段内考虑到这一点。