LiteFlow绝大部分工作都是在启动时完成，包括解析规则，注册组件，组装元信息。而执行链路时几乎对系统没有额外的消耗。框架在设计之初就是为公司的核心业务量身打造，在性能表现问题上格外注意。所以也对核心代码进行了性能方面的优化。

实际表现中，LiteFlow执行效率很高，在公司级核心业务上面，50多个业务组件组成的链路，在实际压测中单点达到了1500的TPS，集群达到了1W以上的TPS，也经历过双11，明星顶流带货等大流量的考验。

虽然LiteFlow框架本身性能很好，但是整体执行效率却依赖实际业务组件的快慢，如果你的组件有大量的循环数据库请求IO，或者有bad sql，又或者有大量的rpc同步调用。那实际TPS也不会很高。但是这是业务组件的问题，而不是LiteFlow框架本身的性能问题。如果你的业务代码很糟糕，那么任何一个框架都无法提高整体系统的TPS/QPS，一个系统整体吞吐量的快慢，不是仅依靠某一款框架能改善的。这点希望大家能明白。

LiteFlow提供了一个实际业务的测试案例，地址为：

测试案例 (opens new window)

这个业务为一个价格计算引擎，有11个业务节点，业务逻辑丰富，只不过数据为mock，不走数据库IO。

基于这个Demo业务进行了压测，压测机器为mac m3 pro ，压测工具为apache jmeter 5.6，容器为springboot自带的tomcat，压测结果为：

300线程并发，循环300次

600并发，循环300次

900并发，循环300次