[distcc] distcc multiple client users

[Martin Pool]

On 22 Jul 2003, Brian Ristuccia <bristucc at sw.starentnetworks.com> wrote:
> Has any work been done in the area of optimizing job distribution with
> multiple distcc client users? It seems the current system can result in
> distcc servers being loaded to death if lots of people decide to compile at
> the same time because the load leveling is done at the client side and one
> user's clients do not know about another user's clients.

If you run the server in --daemon mode, it will regulate the number of
jobs that it accepts and that should prevent it being "loaded to
death".  If the default number of jobs (3 on uniprocessor machines) is
too high, you can change it with -j.

With some inetds such as xinetd there is a similar control feature.

Are you actually seeing problems with multiple clients, or are you
just thinking about it?

> I see that as of distcc-2.5.x, there is now a -j option to the distcc
> server. I suppose in the 3.x protocol this would cause the server to delay
> returning a ready response on the TCP connection if the accepting the job
> would cause the job limit to be exceeded. It seems like it would be possible
> to get better performance especially in the case where large files are being
> compiled, by having the client attempt in parallel to connect to several
> distcc daemons, and then send the job to the one that responds ready first.

Yes, that's basically what is laid out in the protocol-3.txt draft.

> Even better if the ready response included the number of jobs already
> running so that if multiple ready responses came back at almost exactly the
> same time the best of them could be used.

I'm not sure that would really help.  It might cause many clients to
suddenly try to use that host.  The number of running jobs is not a
really accurate measure of how busy the volunteer will be when the new
job has arrived and is ready to run.

> It seems like it would be possible to implement the above system, perhaps in
> a less than elegant form, with the current protocol. For example, if the
> client were to try another distcc server if the first choice was not
> listening, hung up the TCP connection right away, or sent a "go away"
> message all that would be needed is to modify the server to stop listening
> when it was too busy, hang up, or send a "go away" message.

Yes, but but that makes it hard to distinguish servers that are
temporarily busy from servers that are down or failing.

At the moment I think the biggest scheduling problem is that Make
issues jobs unevenly.  In my experiments, the combination of client
and server limits seems to keep all the machines moderately loaded.
If anyone has contrary evidence I'd very much like to hear about it.

--
Martin