<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 9 October 2015 at 12:50, Chris Friesen <span dir="ltr"><<a href="mailto:chris.friesen@windriver.com" target="_blank">chris.friesen@windriver.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Has anybody looked at why 1 instance is too slow and what it would take to<br><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
make 1 scheduler instance work fast enough? This does not preclude the use of<br>
concurrency for finer grain tasks in the background.<br>
</blockquote>
<br></span>
Currently we pull data on all (!) of the compute nodes out of the database via a series of RPC calls, then evaluate the various filters in python code.<br></blockquote><div><br></div><div>I'll say again: the database seems to me to be the problem here.  Not to mention, you've just explained that they are in practice holding all the data in memory in order to do the work so the benefit we're getting here is really a N-to-1-to-M pattern with a DB in the middle (the store-to-DB is rather secondary, in fact), and that without incremental updates to the receivers.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

I suspect it'd be a lot quicker if each filter was a DB query.<br></blockquote><div><br></div><div>That's certainly one solution, but again, unless you can tell me *why* this information will not all fit in memory per process (when it does right now), I'm still not clear why a database is required at all, let alone a central one.  Even if it doesn't fit, then a local DB might be reasonable compared to a centralised one.  The schedulers don't need to work off of precisely the same state, they just need to make different choices to each other, which doesn't require a that's-mine-hands-off approach; and they aren't going to have a perfect view of the state of a distributed system anyway, so retries are inevitable.<br><br></div><div>On a different topic, on the weighted choice: it's not 'optimal', given this is a packing problem, so there isn't a perfect solution.  In fact, given we're trying to balance the choice of a preferable host with the chance that multiple schedulers make different choices, it's likely worse than even weighting.  (Technically I suspect we'd want to rethink whether the weighting mechanism, is actually getting us a benefit.)<br></div><div>-- <br></div><div>Ian.<br></div></div></div></div>