You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicecomb.apache.org by Lance Ju <ju...@gmail.com> on 2018/08/22 13:36:37 UTC

Saga load test & comparison

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

Re: Saga load test & comparison

Posted by Willem Jiang <wi...@gmail.com>.
FYI, we are leveraging the kamon[1] to monitor the internal method call.
In this way we can know which method take the most of time to execute.
Here are some documents[2] and recent PR[3] for this part of work.

[1]https://kamon.io/documentation/get-started/
[2]
https://github.com/apache/incubator-servicecomb-saga/tree/master/saga-performance
[3]https://github.com/apache/incubator-servicecomb-saga/pull/270

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem


On Thu, Aug 23, 2018 at 7:18 AM Willem Jiang <wi...@gmail.com> wrote:

> 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 <ju...@gmail.com> 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
>>
>
>

Re: Saga load test & comparison

Posted by Willem Jiang <wi...@gmail.com>.
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 <ju...@gmail.com> 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
>