| concurrency | icehouse count | juno count | | 1 | 222 | 307 | | 5 | 324 | 1088 | | 10 | 282 | 1271 | | 20 | 22 | 1287 |
Testing based on SqlIcehouseJuno.
In both Icehouse and Juno only keystone, ceilometer-api and ceilometer-collector are running in a pared down devstack. The collector has four workers, the api is under mod_wsgi with 2 process using ten threads apiece.
The scenario creates some users and then iterates through creating a sample and then getting a filtered (
counter_unit = horn) and limited (
20) list of samples. The duration tests do this for however many iterations can be done in 60 seconds. The count tests do 1000 iterations. Timings do not include the time required to set things up, just the iterations.
More detail, including per request times:
Compare with mongo:
In a 60 second run how many transactions (create query + query sample) can be performed? Higher value is better.
How long (seconds) does it take to do 1000 transactions? Lower value is better.
|concurrency | icehouse | juno | | 1 | 257.5 | 178.6 | | 5 | 161.1 | 50.87 | | 10 | 159.8 | 43.37 | | 20 | 144.7 | 42.81 |
It is quite likely the numbers for concurrency 20 are not correct, but I haven't had a chance to trace it yet.
Icehouse v Juno v sql v mongo
The following image shows data from a 60 second run with concurrency of 10.
||transactions|avg. req create|avg. req query| |icehouse.sql|282|1.505|0.412| |icehouse.mongo|277|1.136|0.91| |juno.sql|1271|0.36|0.11| |juno.mongo|1511|0.334|0.061|
Clearly Juno is better but we need to be aware of the number of elements in this stack:
- The rally engine, which uses multiprocessing to achieve concurrency.
- Apache + mod_wsgi to host the api.
- The messaging bus + publishing pipeline + collector.
- The storage implementation.
For those last two items the diff between Juno and Icehouse is large, not just the sql implementation.