技术来了又去，但是一件事保持不变。
在设计企业解决方案时，我们喜欢使我们的生活更轻松的复杂组件，并且作为建筑师和开发人员，我们一直在寻找使我们的生活更轻松的方法。
一种方法是跟上与感兴趣的技术有关的流行新站点。 另一种方法是，以关于技术主题的书籍，杂志或博客的形式尽可能多地阅读。
介绍
在研究领域中，我们可以更深入，更深入地了解我们感兴趣的技术的根源。 例如，在该站点上，您可以找到我在荷兰奈梅亨的拉德布德大学支持通用信息检索研究时所涉及的一些早期作品 。 这项经验表明，观看更严格和更深入的资源非常有价值，这些资源为我感兴趣的技术领域的各种基于科学的会议贡献了研究论文。
当Mark Proctor指出一项复杂事件处理（CEP）引擎的新比较研究 ，其中包括基于JBoss社区的Drools项目引擎时，是时候深入研究本文并检查与JBoss产品相关的结果了。 本文引用的社区组件是Drools项目的一部分，可以在我们直接支持的JBoss业务规则管理系统（BRMS ）和JBoss BPM Suite产品中找到。 使用的社区版本为5.5，该版本已从6.0版及更高版本集成到JBoss BRMS中 。
我确实意识到并不是每个人都喜欢这些论文中用来证明和支持理论结果的严格的数学基础。 因此，为了向您提供有关社区与产品之间的联系的JBoss相关信息，本文将专注于仅提取Drools的CEP相关结果。
您可以免费下载和阅读在第十届网络战争与安全国际会议（ICCWS-2015）上提交的完整原始论文，作者非常乐意将整个论文放在网上。
总览
本文着眼于一类信息系统，该系统将数据和事件收集在一起，以提供在当今复杂的信息技术环境中审核或维护某种形式的安全性的能力。 他们在论文中将这些系统分类为软件信息和事件管理（SIEM）系统，流行的基于规则的开源规则Drools复杂事件处理（CEP）引擎适合作者评估。
作者认为这些系统的最重要特征是“…相关引擎，该引擎用于标准化，减少，过滤和汇总来自一组异构输入的事件。” 本文有望比较并介绍以下相关引擎的性能评估：
- 简单事件关联器（SEC）
- 埃斯珀
- 结脑
- Drools，JBoss BRMS和JBoss BPM Suite中的Red Hat支持
本文的其余部分将参考与受支持的JBoss BRMS相关的结果，该结果可产生Drools CEP引擎，作者在本文中将其视为相关引擎。 请记住，JBoss BPM Suite是JBoss BRMS的超集，因此，在本文中，我们选择专注于JBoss BRMS。
测试体系结构使用一组处理规则通过JBoss BRMS CEP组件推动了负载，监视了进度，然后将结果过滤到报告中。 生成事件以触发规则并以预定义的分布。
该论文还指出，对CEP组件进行了优化，以产生可能的最佳结果，但是作者并未提供任何细节说明。 测试是在虚拟化的Xeon CPU X5660处理器（基于Linux的操作系统）上进行的，已分配了4GB的RAM，并且该测试套件有多次运行。
基准测试
最终数取为三个运行中测得的结果的平均值，并反映了基于执行时间和吞吐量（每秒处理的事件）的测量结果。 以下显示事件数量可变的规则数目的规则和规则数量可变的事件数目的结果。
1. 500条规则集的执行时间和吞吐量
事件按比例扩大，规则集的大小保持不变。
- 1k事件
- 吞吐量– 125个事件/秒
- 10k事件
- 吞吐量– 1111个事件/秒
- 100k事件
- 吞吐量– 6250个事件/秒
- 1百万个事件
- 吞吐量– 14286个事件/秒
与其他引擎相比，事件集从中到大时，我们看到处理吞吐量显着提高，这是按两倍或三倍来衡量的快速相关引擎。 由于索引和引擎设置的初始成本，较小的事件集几乎看不到变化， Mark Proctor在有关这些结果的文章中指出 。
2.一百万个事件集的执行时间和吞吐量
提供的第二个结果基于单个大型事件集和规则集，它们的大小会不断增长。
- 20条规则
- 吞吐量– 21,272个事件/秒
- 200条规则
- 吞吐量– 14,925个事件/秒
- 500条规则
- 吞吐量– 14,286个事件/秒
这些都是很引人注目的，并且随着规则集规模的扩大，性能也会很好地扩展。 同样，较小的规则集会感觉到引擎设置和索引操作的影响，导致标准时间损失随着工作量的增加而变得可以忽略不计。
我们将保留作者提出的结论作为练习供您阅读，但是毫无疑问，无论大小或规则的复杂性，JBoss BRMS CEP组件都提供了一个强大而强大的引擎来处理事件流。
翻译自: https://www.javacodegeeks.com/2015/08/jboss-brms-complex-event-processing-cep-performance-benchmark.html
