Open Stack

Hi,

Your result is interesting and not surprising due to the different design
you have described.
The Ceilo team will work on the improvements IIUC.
I found two relevant links [1] [2]

@jay : the first case seems to be impossible, no scalable .. I bet for the
last :)

@June li
I am curious to know how have you generate load to Ceilometer with Ganglia ?

what was the system usage of your servers during the 2 tests  ? cpu, mem,
io..
what are response time for alarm evaluations for Ceilometer, 50 seconds in
mean  ?

btw thank you for sharing your tests.

[1] https://wiki.openstack.org/wiki/Ceilometer/AlarmImprovements
[2]
https://etherpad.openstack.org/p/icehouse-summit-ceilometer-future-of-alarming



2014/1/7 Jay Pipes <jaypipes at gmail.com>

> On Mon, 2014-01-06 at 00:14 +0000, Deok-June Yi wrote:
> > Hi, Ceilometer team.
> >
> > I'm writing to share my load test result and ask you for advice about
> > Ceilometer.
> >
> > Before starting, for whom doesn’t know Synaps [1], Synaps is
> > 'monitoring as a service' project that provides AWS CloudWatch
> > compatible API. It was discussed to be merged with Ceilometer project
> > at Grizzly design phase, but Synaps developers could not join the
> > project for it at that time. And now Ceilometer has its own alarming
> > feature.
> >
> > A few days ago, I installed Ceilometer and Synaps on my test
> > environment and ran load test for over 2 days to evaluate their
> > alarming feature in the aspect of real-time requirement. Here I attached
> > test environment diagram and test result. The load model was as below.
> > 1.  Create 5,000 alarms
> > 2.  [Every 1 minute] Create 5,000 samples
> >
> > As a result, alarm evaluation time of Ceilometer was not predictable,
> > whereas Synaps evaluated all alarms within 2 seconds every minute.
> >
> > This comes from two different design decisions for alarm evaluation
> > between Ceilometer and Synaps. Synaps does not read database but read
> > in-memory and in-stream data for alarming while Ceilometer involves
> > database read operations with REST API call.
>
> So you are saying that the Synaps server is storing 14,400,000 samples
> in memory (2 days of 5000 samples per minute)? Or are you saying that
> Synaps is storing just the 5000 alarm records in memory and then
> processing (determining if the alarm condition was met) the samples as
> they pass through to a backend data store? I think it is the latter but
> I just want to make sure :)
>
> Best,
> -jay
>
> > I think Ceilometer is better to allow creating alarms with more complex
> > query on metrics. However Synaps is better if we have real-time
> > requirement with alarm evaluation.
> >
> > So, how about re-opening the blueprint, cw-publish [2]?  It was
> > discussed and designed [3] at the start of Grizzly development cycle,
> > but it has not been implemented. And now I would like to work for it. Or
> > is there any good idea to fulfill the real-time requirement with
> > Ceilometer?
> >
> > Please, don't hesitate in contacting me.
> >
> > Thank you,
> > June Yi
> >
> > [1] https://wiki.openstack.org/Synaps
> > [2] https://blueprints.launchpad.net/ceilometer/+spec/cw-publish
> > [3]
> https://wiki.openstack.org/wiki/Ceilometer/blueprints/multi-publisher
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140108/752c9a8b/attachment.html>