LiteFlow的性能如何?

官网:liteflow.cc/

Gitee:gitee.com/dromara/lit...

Github:github.com/dromara/lit...

LiteFlow是一个现代化的开源规则引擎框架,以下文中简称LF。

对于一款规则引擎而言,性能是至关重要的。

LiteFlow在上面花了大量功夫,确保LF是一款性能极高的规则引擎。

加载性能测试

LF中所有的EL规则以及脚本都是在启动时进行加载的,我们进行了一系列简单的测试:

环境为:JDK17,LiteFlow 2.11.4,Mac m3 pro,每条chain里含有14个组件

构建1w个chain进行启动

最后,1w个chain的parser耗时12秒。

2.11.4正式版中新增了一个liteflow.fast-load的配置参数,如果把这个设为true。再进行测试:

最后,1w个chain在快速load的模式下耗时3秒。

parser的性能耗时是线性增长的,如果10w条流程,大家把耗时乘以10就是了。

但是我并不推荐所有的人把快速load模式打开,因为快速load模式牺牲了热更新时的平滑性。换句话说就是,在正常模式下,如果当你热更新时正好有正在执行的流程,那么正在执行的流程是会用老的链路的,只有下一次才会用最新的链路。如果你打开了快速load模式,那么在热更新时,正好在执行过程中的流程有可能前半部分是老的流程,而后半部分有可能读到新的流程。这样就造成了不一致了。

当然这种场景是非常极端的场景,在普通的场景中,可能根本也不需要保持热更新时的平滑性。所以fast-load模式是有代价的。鱼和熊掌不可兼得。看项目要求了。

其实就算是12秒解析1w个流程,也不算慢了。我也无法想象什么样的项目需要有几w个流程。

事实证明,LF解析的速度是不慢的。

当然在2.11.4中对解析速度进行了优化,2.11.4之前的版本可能解析时间更长一点。推荐大家升级到最新的2.11.4.2。

执行性能测试

环境为:JDK17,LiteFlow 2.11.4,Mac m3 pro,14个组件,其中包含2个Groovy脚本组件,含具体业务,当然我把IO都去掉了,LiteFlow的日志打印关闭。压测软件为apach-jmeter 5.6。

我们分别设置以下几档:

300并发,每个并发执行100次,一共3w请求

600并发,每个并发执行200次,一共12w请求

900并发,每个并发执行300次,一共27w请求

条件:300并发,每个并发执行100次,一共3w请求

结果:3032 tps

条件:600并发,每个并发执行200次,一共12w请求

结果:11726 tps

条件:900并发,每个并发执行300次,一共27w请求

结果:24648 tps

事实证明,哪怕在带有脚本组件的情况下,LF的执行效率依旧是非常快速的。

所以请大家放心。LF规则引擎的性能是绝对足以承载您的业务的。

但是实际项目性能的高低很大程度上取决于您的组件写的如何,如果您的组件中有一个慢sql,那么即便用了LF也无法测出如此性能,这点相信大家明白。

相关推荐
代码之光_198013 分钟前
保障性住房管理:SpringBoot技术优势分析
java·spring boot·后端
ajsbxi18 分钟前
苍穹外卖学习记录
java·笔记·后端·学习·nginx·spring·servlet
StayInLove37 分钟前
G1垃圾回收器日志详解
java·开发语言
对许41 分钟前
SLF4J: Failed to load class “org.slf4j.impl.StaticLoggerBinder“
java·log4j
鹿屿二向箔42 分钟前
基于SSM(Spring + Spring MVC + MyBatis)框架的咖啡馆管理系统
spring·mvc·mybatis
无尽的大道1 小时前
Java字符串深度解析:String的实现、常量池与性能优化
java·开发语言·性能优化
小鑫记得努力1 小时前
Java类和对象(下篇)
java
binishuaio1 小时前
Java 第11天 (git版本控制器基础用法)
java·开发语言·git
zz.YE1 小时前
【Java SE】StringBuffer
java·开发语言
老友@1 小时前
aspose如何获取PPT放映页“切换”的“持续时间”值
java·powerpoint·aspose