Hi, everyone.
The feature of saga transaction in ShardingSphere has been basically completed by integrating servicecomb-saga-actuator. Recently, we used Sharding-JDBC to test the performance of Saga transactions. There are results for two kinds of environments. First result comes from local environment which including 2 cores and 16G RAM The connection pool size, thread pool size of saga-actuator and thread pool size of Sharding-JDBC all are 50. ---------------- result for local environment ---------------- |Tx Type|Thread Number|Average response(ms)| TPS | | No Tx | 50 | 337 | 140 | | saga | 50 | 395 | 120 | | local | 50 | 323 |143| | xa | 50 | 301 |154| | No Tx | 100 | 605 | 158 | | saga | 100 | 789 | 120 | ---------------- result for local environment ---------------- Second result comes from test environment which 256cores and 300+G RAM The connection pool size, thread pool size of saga-actuator and thread pool size of Sharding-JDBC all are 200. ---------------- result for test environment ---------------- |Tx Type|Thread Number|Average response(ms)| TPS | | No Tx | 200 | 95 |2002| | saga | 200 | 351 |1700| | local | 200 | 64 |2868| | xa | 200 | 98 |2012| ---------------- result for test environment ---------------- And I do echo test with emptyTransport which do not execute SQL in saga, the result is TPS 457 in local and 3200 in test environment. if saga do persistence to log file, the TPS of saga will nose dive to 70 in local and 600+ in test environment
