+1 for performance analysis to understand what needs to be optimised. Metering should be light-weight.
For those of us running in production, we don't have an option to turn ceilometer off some of the time. That we are not able to run through the gate tests hints that there are optimisations that are needed. For example, turning on ceilometer caused a 16x increase in our Nova API call rate, see http://openstack-in-production.blogspot.ch/2014/03/cern-cloud-architecture-update-for.html for details. Tim > -----Original Message----- > From: Sean Dague [mailto:[email protected]] > Sent: 20 March 2014 11:16 > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Ceilometer][QA][Tempest][Infra] Ceilometer > tempest testing in gate > ... > > While I agree that Tempest's job is not to test performance, we do have to > give some basic sanity checking here that the software is running in some > performance profile that we believe is base usable. > > Based on the latest dstat results, I think that's a dubious assessment. > The answer on the collector side has to be something other than horizontal > scaling. Because we're talking about the collector being the 3rd highest > utilized process on the box right now (we should write a dstat plugin to give > us cumulative data, just haven't gotten there yet). > > So right now, I think performance analysis for ceilometer on sqla is > important, really important. Not just horizontal scaling, but actual > performance profiling. > > -Sean > > -- > Sean Dague > Samsung Research America > [email protected] / [email protected] > http://dague.net _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
