我们使用Drools作为解决方案的一部分，在一个非常激烈的处理应用程序中充当一种过滤器，可能在500,000个工作内存对象上运行多达100个规则。 事实证明它非常慢。 其他人是否有在批处理类型处理应用程序中使用Drools的经验？
答案 0 :(得分：4)
取决于你的规则 - 500K对象是合理的给定足够的内存（它必须在内存中填充RETE网络，因此内存使用是500K对象的倍数 - 即对象的空间+网络结构的空间，索引等） - 它可能你正在寻找磁盘，这将是非常慢的。
当然，如果您的规则与相同类型的事实的组合匹配，那么可能会导致组合爆炸尝试，即使您有1条规则也会非常慢。 如果您有关于分析的更多信息，那么可能有助于解决问题。
答案 1 :(得分：4)
我使用了具有超过1M事实的有状态工作记忆的Drools。通过对规则和底层JVM进行一些调整，初始启动几分钟后性能可以非常好。如果您需要更多详细信息，请与我们联系。
答案 2 :(得分：3)
我没有使用最新版本的Drools（上次我使用它是大约一年前），但当时我们的高负载基准测试证明它非常慢。基于我们的大部分架构后，我们感到非常失望。
至少我记得有关drools的好事是他们的开发团队在IRC上可用并且非常有帮助，你可以尝试一下，毕竟他们是专家： irc.codehaus.org #drools < /强>
答案 3 :(得分：2)
我自己只是在学习流口水，所以也许我错过了一些东西，但为什么整批五十万个物品一次性加入工作记忆？我能想到的唯一原因是，只有当批次中的两个或多个项目相关时，才会有规则启动。
如果不是这种情况，那么也许你可以使用无状态会话并一次断言一个对象。在这种情况下，我假设规则将运行500k倍。
即使是这种情况，您的所有规则都需要访问所有500k对象吗？您是否可以通过逐个应用每个项目规则来加快速度，然后在第二个处理阶段使用不同的规则库和工作内存应用批处理级别规则？这不会改变数据量，但RETE网络会更小，因为简单的规则将被删除。
另一种方法是在第二阶段尝试识别相关的对象组并在组中断言对象，进一步减少工作内存中的数据量以及拆分RETE网络。
答案 4 :(得分：1)
Drools并非真正设计用于在大量对象上运行。它针对在一些对象上运行复杂规则进行了优化。
每个附加对象的工作内存初始化太慢，缓存策略设计为每个工作内存对象工作。
答案 5 :(得分：1)
解析了几千个对象后，我遇到了OutOfMemory错误的问题。设置不同的默认优化器解决了这个问题。
OptimizerFactory.setDefaultOptimizer(OptimizerFactory.SAFE_REFLECTIVE);
答案 6 :(得分：0)
我们也在看drools，但对我们来说，对象的数量很少，所以这不是问题。我确实记得读过同一算法的备用版本，它们更多地考虑了内存使用情况，并且针对速度进行了优化，同时仍然基于相同的算法。不知道是否有任何一个使它成为真正可用的库。
答案 7 :(得分：0)
使用无状态会话并一次添加一个对象？
答案 8 :(得分：-1)
也可以使用参数设置此优化程序 -Dmvel2.disable.jit =真