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也无法测出如此性能,这点相信大家明白。

相关推荐
弗拉唐43 分钟前
springBoot,mp,ssm整合案例
java·spring boot·mybatis
oi771 小时前
使用itextpdf进行pdf模版填充中文文本时部分字不显示问题
java·服务器
2401_857610032 小时前
SpringBoot社团管理:安全与维护
spring boot·后端·安全
少说多做3432 小时前
Android 不同情况下使用 runOnUiThread
android·java
知兀2 小时前
Java的方法、基本和引用数据类型
java·笔记·黑马程序员
蓝黑20202 小时前
IntelliJ IDEA常用快捷键
java·ide·intellij-idea
Ysjt | 深2 小时前
C++多线程编程入门教程(优质版)
java·开发语言·jvm·c++
凌冰_2 小时前
IDEA2023 SpringBoot整合MyBatis(三)
spring boot·后端·mybatis
shuangrenlong2 小时前
slice介绍slice查看器
java·ubuntu