Release Infrastructure/BOSS/Performance/Results

This page is to talk about the way of BOSS performance testing.

Contents 1 Rate 2 Test Method 3 Test Environment 4 Test Scripts 5 Test Cases 6 Issues Found 7 TODO 8 Some Thoughts

Rate

• "Rate" is to measure the throughput of BOSS - how many workflows can be handled in one second. With the "Rate" of different workflow request scales, we will have a view of the BOSS capability for different service levels.

Test Method

• The way to get "Rate" is straightforward. In each test case, sending specified number of workflows(such 3000, 20000...) to BOSS then record the start and end time. Then it's easy to get the "Rate" for that test case.

Test Environment

• Hardware: CPU E5520(x16 cores), RAM 16G, openSUSE 11.2
• Virtual Machine: CPU E8400(x1 core), RAM 512M, openSUSE 11.2
• BOSS packages taken from OBS(https://build.opensuse.org/project/show?project=Maemo%3AMeeGo-Infra%3ABOSS)

Test Scripts

We created the test suit(http://gitorious.org/boss-performance-test) including:

• A client to send multiple workflows to BOSS(or to say "launch workflows") at once time.
• A logger plug-in of engine, record interesting engine internal messages to somewhere which will be used to calculate time durations of workflow, participant, etc.
• An utility to analyze the time data. Here we select the earliest start time and latest end time of all workflows to calculate the whole duration.

Test Cases

• Test Case Set 1

In this case set, we test the rates for launching different workflow scales(for N=[several hundreds, ..., several thousands]). Here we also compared the situation of different number of workers. And the CPU/MEM/DISK load is record.

* Raw data and graph

* CPU/MEM/DISK load for 10k and 20k cases

• Test Case Set 2

Here we got the "reponse time" testing results. The way is to launch 1k workflows each time after previous 1k workflows finished. Observing the durations for executing each 1k workflows we can get the response time trend. Following are results on VM and HW

Issues Found

• Observed losting several workflows(19995 for 20000 workflows; 9999 for 10000 workflows)
• Engine crashed in some cases:
  • Case for 100k workflows launched on HW: finished around 60k workflows then engine crashed
  • Case for 30k workflows launched on Virtual Machine(1 CPU, 512M): finished around 20k workflows then engine crashed
• Memory leaking: memory used by engine was keeping even all workflows finished

TODO

• think about why we lost workflows in some cases
• different storage

Some Thoughts

• Using more workers can boost performance?
• Using multiple engines can boost performance?