<p dir="ltr"><br>
On Jul 23, 2013 3:44 PM, "Ian Wells" <<a href="mailto:ijw.ubuntu@cack.org.uk">ijw.ubuntu@cack.org.uk</a>> wrote:<br>
><br>
> > * periodic updates can overwhelm things. Solution: remove unneeded updates,<br>
> > most scheduling data only changes when an instance does some state change.<br>
><br>
> It's not clear that periodic updates do overwhelm things, though.<br>
> Boris ran the tests. Apparently 10k nodes updating once a minute<br>
> extend the read query by ~10% (the main problem being the read query<br>
> is abysmal in the first place). I don't know how much of the rest of<br>
> the infrastructure was involved in his test, though (RabbitMQ,<br>
> Conductor).</p>
<p dir="ltr">A great openstack at scale talk, that covers the scheduler <a href="http://www.bluehost.com/blog/bluehost/bluehost-presents-operational-case-study-at-openstack-summit-2111">http://www.bluehost.com/blog/bluehost/bluehost-presents-operational-case-study-at-openstack-summit-2111</a><br>
</p>
<p dir="ltr">><br>
> There are reasonably solid reasons why we would want an alternative to<br>
> the DB backend, but I'm not sure the update rate is one of them. If<br>
> we were going for an alternative the obvious candidate to my mind<br>
> would be something like ZooKeeper (particularly since in some setups<br>
> it's already a channel between the compute hosts and the control<br>
> server).<br>
> --<br>
> Ian.<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</p>