Drools 在大批量生产过程中使用流液
我们使用Drools作为解决方案的一部分，在一个非常密集的处理应用程序中充当一种过滤器，可能在500000多个工作内存对象上运行多达100条规则。 结果是速度非常慢。Drools 在大批量生产过程中使用流液,drools,Drools,我们使用Drools作为解决方案的一部分，在一个非常密集的处理应用程序中充当一种过滤器，可能在500000多个工作内存对象上运行多达100条规则。 结果是速度非常慢。 还有人有在批处理应用程序中使用Drools的经验吗？我还没有使用最新版本的Drools（上次使用它大约是一年前），但当时我们的高负载基准测试证明它非常慢。在我们的大部分架构都基于它之后，这是一个巨大的失望 关于drools，至少我记得他们的开发团队在IRC上很有用，你可以试试看，他们毕竟是专家：IRC.codehaus.org#d
还有人有在批处理应用程序中使用Drools的经验吗？我还没有使用最新版本的Drools（上次使用它大约是一年前），但当时我们的高负载基准测试证明它非常慢。在我们的大部分架构都基于它之后，这是一个巨大的失望
关于drools，至少我记得他们的开发团队在IRC上很有用，你可以试试看，他们毕竟是专家：IRC.codehaus.org#droolsdrools并不是真正为在大量对象上运行而设计的。它针对在几个对象上运行复杂规则进行了优化
每个附加对象的工作内存初始化速度太慢，缓存策略设计为每个工作内存对象都能工作。我们也在研究drools，但对我们来说，对象数量太少，所以这不是问题。我确实记得读到过，同一算法的其他版本考虑到了更多的内存使用，并且在仍然基于同一算法的情况下对速度进行了优化。但是，不确定是否有任何对象已将其放入真正可用的库中。某种程度上取决于您的规则-如果有足够的内存，500K对象是合理的（它必须在内存中填充一个RETE网络，因此内存使用量是500K对象的倍数-即对象空间+网络结构、索引等的空间）-可能您正在分页到磁盘，这会非常慢 当然，如果您有匹配相同类型事实的组合的规则，那么可能会导致大量组合的尝试，即使您有1条规则，这也会非常缓慢。
如果你有更多关于你正在做的分析的信息，这可能会有助于找到可能的解决方案。我自己也在学习drools，所以可能我遗漏了一些东西，但是为什么一次就将整批五十万个对象添加到工作记忆中呢？我能想到的唯一原因是，只有当批次中的两个或多个项目相关时，才会有规则生效 如果不是这样，那么也许您可以使用无状态会话，一次声明一个对象。我想在这种情况下，规则的运行速度会快50万倍 即使是这样，您的所有规则是否都需要访问所有500k对象？您能否通过一次应用一条每项规则，然后在处理的第二阶段使用不同的规则库和工作内存应用批处理级别的规则来加快速度？这不会改变数据量，但RETE网络会更小，因为简单的规则会被删除
另一种方法是尝试识别相关的对象组，并在第二阶段对组中的对象进行断言，进一步减少工作内存中的数据量，并分割网络。使用无状态会话，一次添加一个对象？我使用了Drools，它有状态工作内存包含超过1M个事实。通过对规则和底层JVM进行一些调优，初始启动几分钟后，性能可能会非常好。如果您想了解更多详细信息，请告诉我。在解析几千个对象后，我遇到了OutOfMemory错误。设置不同的默认优化器解决了这个问题
OptimizerFactory.setDefaultOptimizer(OptimizerFactory.SAFE_REFLECTIVE);
也可以使用参数设置此优化器
-Dmvel2.disable.jit=true我对这些细节感兴趣，你能和我们分享一下吗？我也在大量数据上运行Drools，任何调整都会很棒。请分享详细信息，我很感兴趣。遗憾的是，我已经记不起太多了！您好@Michael，请您再详细说明一下磁盘分页。当我不断地插入事实时，我面临着缓慢的问题。对于最初的几千个事实，它运行良好。但稍后，它将停止调用规则，并且很少在某个时间间隔内执行一组规则。这有什么问题吗？有人能说说上面的问题吗？内存中真的有可能存在许多事实并同时以高性能调用规则吗。