Just some added info for that talk, we are using qpid as our messaging backend. I have no data for RabbitMQ, but our schedulers are _always_ behind on processing updates. It may be different with rabbit.
-Mike On Tue, Jul 23, 2013 at 1:56 PM, Joe Gordon <joe.gord...@gmail.com> wrote: > > On Jul 23, 2013 3:44 PM, "Ian Wells" <ijw.ubu...@cack.org.uk> wrote: > > > > > * periodic updates can overwhelm things. Solution: remove unneeded > updates, > > > most scheduling data only changes when an instance does some state > change. > > > > It's not clear that periodic updates do overwhelm things, though. > > Boris ran the tests. Apparently 10k nodes updating once a minute > > extend the read query by ~10% (the main problem being the read query > > is abysmal in the first place). I don't know how much of the rest of > > the infrastructure was involved in his test, though (RabbitMQ, > > Conductor). > > A great openstack at scale talk, that covers the scheduler > http://www.bluehost.com/blog/bluehost/bluehost-presents-operational-case-study-at-openstack-summit-2111 > > > > > There are reasonably solid reasons why we would want an alternative to > > the DB backend, but I'm not sure the update rate is one of them. If > > we were going for an alternative the obvious candidate to my mind > > would be something like ZooKeeper (particularly since in some setups > > it's already a channel between the compute hosts and the control > > server). > > -- > > Ian. > > > > _______________________________________________ > > 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
