Hi Mike,
On Wed, Jul 24, 2013 at 1:01 AM, Mike Wilson <[email protected]> wrote: > Again I can only speak for qpid, but it's not really a big load on the > qpidd server itself. I think the issue is that the updates come in serially > into each scheduler that you have running. We don't process those quickly > enough for it to do any good, which is why the lookup from db. You can see > this for yourself using the fake hypervisor, launch yourself a bunch of > simulated nova-compute, launch a nova-scheduler on the same host and even > with 1k or so you will notice the latency between the update being sent and > the update actually meaning anything for the scheduler. > > I think a few points that have been brought up could mitigate this quite a > bit. My personal view is the following: > > -Only update when you have to (ie. 10k nodes all sending update every > periodic interval is heavy, only send when you have to) > -Don't fanout to schedulers, update a single scheduler which in turn > updates a shared store that is fast such as memcache > > I guess that effectively is what you are proposing with the added twist of > the shared store. > Absolutely agree with this. Especially with using memcached (or redis) as common storage for all schedulers. Best regards, Boris Pavlovic --- Mirantis Inc.
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
