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 <jaypi...@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@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev