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