JBoss BRMS 复杂事件处理 (CEP) 性能基准

一则或许对你有用的小广告

欢迎加入小哈的星球 ,你将获得:专属的项目实战 / Java 学习路线 / 一对一提问 / 学习打卡/ 赠书活动

目前,正在 星球 内带小伙伴们做第一个项目:全栈前后端分离博客项目,采用技术栈 Spring Boot + Mybatis Plus + Vue 3.x + Vite 4手把手,前端 + 后端全栈开发,从 0 到 1 讲解每个功能点开发步骤,1v1 答疑,陪伴式直到项目上线,目前已更新了 204 小节,累计 32w+ 字,讲解图:1416 张,还在持续爆肝中,后续还会上新更多项目,目标是将 Java 领域典型的项目都整上,如秒杀系统、在线商城、IM 即时通讯、权限管理等等,已有 870+ 小伙伴加入,欢迎点击围观

技术来来去去,但有一件事是不变的。

我们喜欢在设计企业解决方案时让我们的生活更轻松的复杂组件,作为架构师和开发人员,我们一直在寻找让我们的生活更轻松的方法。做到这一点的一种方法是跟上与感兴趣的技术相关的流行新站点。另一种方法是尽可能多地阅读有关技术主题的书籍、杂志或博客。

介绍

在研究领域可以更微妙、更深入地探究我们感兴趣的技术的根源。例如,在这个站点上,您会发现 我在荷兰奈梅亨拉德堡德大学支持通用信息检索研究时参与的一些早期工作 。这段经历表明,关注更严谨、更深入的资源的价值,这些资源为我感兴趣的技术领域的各种科学会议提供研究论文。

Mark Proctor 指出复杂事件处理 (CEP) 引擎(包括基于 JBoss 社区的 Drools 项目引擎)的新比较研究 时,是时候深入研究该论文并检查与 JBoss 产品相关的结果了。本文中引用的社区组件是 Drools 项目 的一部分,可以在我们直接支持的 JBoss 业务规则管理系统 (BRMS ) 和 JBoss BPM Suite 产品中找到。使用的社区版本是 5.5,它 从 6.0 版及更高版本集成到 JBoss BRMS 中


我确实意识到并不是每个人都喜欢这些论文中用来证明和支持理论结果的严谨且通常是数学基础。因此,为了向您提供关于我们在社区和产品之间的联系的 JBoss 相关信息,本文将专注于仅提取 Drools 的 CEP 相关结果。

您可以免费下载和阅读在 第 10 届网络战与安全国际会议 (ICCWS-2015) 上发表的完整原始论文,因为作者非常友好地将整篇论文放在网上。


概述

本文着眼于一类信息系统,该系统将数据和事件收集在一起,以提供在当今复杂的信息技术环境中审计或维护某种形式的安全性的能力。他们在论文中将这些系统归类为软件信息和事件管理 (SIEM) 系统,其中流行的基于规则的开源 Drools 复杂事件处理 (CEP) 引擎适合作者的评估。

作者认为这些系统最重要的特征是“......关联引擎,用于规范化、减少、过滤和聚合来自一组异构输入的事件。”该论文承诺比较和呈现以下关联引擎的性能评估:

  • 简单事件相关器 (SEC)
  • 异能者
  • 节点脑
  • Drools,由 Red Hat 在 JBoss BRMS 和 JBoss BPM Suite 中提供支持

本文的其余部分将参考与支持的 JBoss BRMS 相关的结果,该 BRMS 将 Drools CEP 引擎产品化,作者在本文中将其视为关联引擎。请记住,JBoss BPM Suite 是 JBoss BRMS 的超集,因此我们选择在本文中重点介绍 JBoss BRMS。

使用一组处理规则通过 JBoss BRMS CEP 组件推送负载的测试架构监控进度,然后将结果过滤到报告中。生成事件以触发规则并在预定义的分布中。

该论文还指出,CEP 组件经过优化以产生可能的最佳结果,但作者没有提供任何关于这可能需要什么的细节。测试是在虚拟化的 Xeon CPU X5660 处理器、基于 Linux 的操作系统上完成的,分配了 4GB RAM 并且测试套件运行了多次。

基准

最终数字取为三个运行测量结果的平均值,并反映基于执行时间和吞吐量(每秒处理的事件)的测量结果。下面显示了设置数量的规则和可变数量的事件的结果以及设置数量的事件和可变数量的规则的结果。

1. 500条规则集的执行时间和吞吐量

事件按比例放大,规则集的大小保持不变。

  • 1k 个事件
    • 吞吐量 - 125 个事件/秒
    • 时间 - 8 秒
  • 10k 事件
    • 吞吐量 - 1111 个事件/秒
    • 时间 - 9 秒
  • 10 万个事件
    • 吞吐量 - 6250 个事件/秒
    • 时间 - 16 秒
  • 100万个事件
    • 吞吐量 - 14286 个事件/秒
    • 时间 - 70 秒

与其他引擎相比,对于中等到较大的事件集,我们看到处理吞吐量显着增加,作为快速相关引擎的衡量标准是两倍或三倍。由于索引和引擎设置的初始成本,较小的事件集几乎没有变化, Mark Proctor 在他关于这些结果的文章中指出了这一点

2. 100万个事件集的执行时间和吞吐量

提供的第二个结果基于单个大型事件集和规模不断增长的规则集。

  • 20条规则
    • 吞吐量 - 21,272 个事件/秒
    • 时间 - 47 秒
  • 200条规则
    • 吞吐量 - 14,925 个事件/秒
    • 时间 - 67 秒
  • 500条规则
    • 吞吐量 - 14,286 个事件/秒
    • 时间 - 70

这些都是戏剧性的,并且随着规则集规模的扩大,性能也得到了很好的扩展。同样,较小的规则集感觉 引擎设置和索引操作的影响导致标准时间损失随着工作负载的增加变得可以忽略不计。

我们将把作者给出的结论作为练习留给您阅读,但毫无疑问,JBoss BRMS CEP 组件提供了一个可靠而强大的引擎来处理您的事件流,无论其大小或规则的复杂性如何。