Just a quick note for the test case background, all the tests are based on the saga-spring-demo[1]
In this demo, the booking service calls the car service and the hotel service, all of these tests don't have any database option. It looks the pack (Omega and Alpha) introduced some overhead for the transaction coordination, we will keep digging the detail and doing the performance tuning. [1] https://github.com/apache/incubator-servicecomb-saga/tree/master/saga-demo/saga-spring-demo Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Wed, Aug 22, 2018 at 9:36 PM, Lance Ju <[email protected]> wrote: > Hi, team, > I've made a simple test on saga performances, with 3 > * Test scenarios:* > > - Disable omega(run the original business without saga) > - Enable omega and handle saga events in Redis > - Enable omega and handle saga events in PostgreSQL > > * The test environment:* > > > - 3 VirtualBox machines as a Kubernetes cluster on a bare metal > - K8S Cluster Node info: > - Memory: 4 GiB > - CPU: 4 Cores > - Disk: SSD > > *The test schema:* > > - Test with JMeter, start 100 testing threads within 5 minutes, the > whole test lasts 10 minutes. > - 10% of invalid request that will cause AbortEvent and trigger > compensation. > > > * The test result:* > SCENARIO1(Without saga): > Total requests: 401,257, avg QPS: 668, avg Response time: 11.82 ms > > SCENARIO2(Saga in Redis): > Total requests: 200,085, avg QPS: 333, avg Response time: 125 ms > > SCENARIO3(Saga in Postgres): > Total requests: 132,100, avg QPS: 220, avg Response time: 241 ms > > I've put the detail on google sheet: > > https://docs.google.com/spreadsheets/d/12eiveBPvRUgDB1h5oyrDB6Nuj- > sXYAhw8lb6i-bNS8A/edit?usp=sharing >
