Most of LiteFlow's work is done at startup, including parsing rules, registering components, and assembling meta-information. And there is almost no additional consumption to the system when the link is executed. The framework was designed from the beginning for the company's core business, with special attention to performance. Therefore, the core code has also been optimized for performance.
In actual performance, LiteFlow's execution efficiency is very high. In the company-level core business, the chain composed of more than 50 business components has reached 1,500 TPS at a single point in the actual stress test and other large traffic tests.
Although the performance of the LiteFlow framework is very good, the execution efficiency depends on the speed of the actual business components. If your components have a large number of cyclic database requests for IO, or bad SQL, or a large number of RPC synchronous calls. Then the actual TPS will not be very high. This is a business component issue, not a performance issue with the LiteFlow framework. If your business code is bad, then no framework can improve the TPS/QPS of the overall system. The overall throughput of a system cannot be improved only by a certain framework. I hope everyone can understand this.
LiteFlow provides an actual business test case at:
This business is a price calculation engine with 11 business nodes and rich business logic, but the data is mock and does not use database IO.
We did a stress test based on this Demo business. The stress testing machine was mac m1 pro, the stress testing tool was apache jmeter, and the stress testing results were: