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