Open Stack

Hi, Swann!

Thanks for your feedback)



On Wed, Apr 23, 2014 at 2:33 PM, Swann Croiset <swannon at gmail.com> wrote:
> Hi Ilya,
>
> Interresting, thanks for sharing.
> So the quick conclusion to your numbers seems indicated that mongodb is more
> efficient for both reading and writing,
> except for 2 cases for retrieving data (meters and resouces listing) ..
>

It's not so indisputable fact. Performance fall may happen due to
cluster VMs base.
For future tests we've already added standalone mysql and standalone
hbase backend.
Also we will deploy mongo cluster on vms in the nearest future

> However for the reading operations,
> it's should be confirmed (or precised) where the time is really spent, would
> be interresting to compute the distribution of times spent by each layer :
> backend -> api -> cli  .. similarly to what you did for collector by custom
> logging (or by instrumentation..)
>
> To add additional use cases (and to be more relevant) it will be good to use
> queries executed by billing systems or the alarm evaluator aka filtering a
> limited subsets of samples (by resource and/or user and/or tenant) .. to see
> the numbers without retrieving ten of thousands of samples.

They are good ideas. I'll add it to tests and show results as soon as possible.

> btw, others indicators should help to give a good picture, I see for now:
> errors rate, queue lenght (rabbit), returned samples|meters|resources by API
> calls, missing samples (after the populating)
> and some system metrics also.

In present time we are calculating the time which messages are waiting
for in rabbitmq queue. This metric has the same meaning as queue
length. Also we logs backend errors but not so many errors as we might
expect happens in tests.


> what was the caracteristics of serveurs used for these load test?

Controller with 16Gb RAM, 8 procs and 3 VMs with 8 GB RAM and 8 procs
(for Hbase).



Best regards,

Tyaptin Ilia,

Intern Software Engineer.