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