<div dir="ltr">Hi Mike,<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 24, 2013 at 1:01 AM, Mike Wilson <span dir="ltr"><<a href="mailto:geekinutah@gmail.com" target="_blank">geekinutah@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div>



<br></div><div>I think a few points that have been brought up could mitigate this quite a bit. My personal view is the following:</div><div><br></div><div>-Only update when you have to (ie. 10k nodes all sending update every periodic interval is heavy, only send when you have to)</div>



<div>-Don't fanout to schedulers, update a single scheduler which in turn updates a shared store that is fast such as memcache</div><div><br></div><div>I guess that effectively is what you are proposing with the added twist of the shared store.</div>


</div></blockquote><div><br></div><div><br></div><div>Absolutely agree with this. Especially with using memcached (or redis) as common storage for all schedulers. </div><div><br></div><div>Best regards,</div><div>Boris Pavlovic</div>
<div>---</div><div>Mirantis Inc. </div><div><br></div></div></div></div>