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.
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. 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. 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. Thoughts? -- Brian Ristuccia [EMAIL PROTECTED] [EMAIL PROTECTED] __ distcc mailing list http://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/cgi-bin/mailman/listinfo/distcc
