由于distcc不能保持状态并且只能发送作业和标头，并且只能让那些服务器仅使用刚发送的数据进行预处理和编译，因此我认为最新的distcc在可伸缩性方面存在问题。
在我的本地构建环境中有appx。要构建10,000个c / c ++文件，当有20个构建服务器时，我的速度只能比不使用distcc（但使用make -j）快2倍。
您认为出了什么问题？
如果有人使用make -j和distcc达到了10到20倍的可伸缩性，请告诉我。
以下产品声称无法使make -j和distcc的扩展速度快于5倍。
http://www.electric-cloud.com/products/electricaccelerator.php
我认为可以通过以下方法来改进：
让distccd服务器维护会话
绑在这些会话上，它们将缓存自己的标题目录
预处理将根据distccd服务器的需求完成
这将通过LD_PRELOADed库libdistcc.so完成，该库将替换stat / open syscalls并通过网络获取头文件。
...
有人做过这种事吗？
我认为Electric Cloud可以做类似的事情，但我认为我们还有更多空间可以优化：
服务器应该在真正快速的网络文件系统上共享相同的源代码存储库。
我们应该进行构建文件解析，并包括并行的头解析。
如果不大幅度更改版本说明，似乎很难。
任何想法，现有技术，解决方法都是可以接受的。
最佳答案
是的，distcc可以扩展到5倍以上。
我们必须找出您的环境中的限制因素。
一个常见的问题是您的makefile不允许它一次实际分发多个文件。您可以看一下正在运行多少个编译器进程。如果这是问题，则可能需要调试makefile以允许更多的并行性。
客户端由于某些原因可能无法分发许多作业。 distcc客户端日志将告诉您是否是这种情况。
也许由于某种原因，客户超负荷了，无法足够快地完成工作。但是，您很可能在达到此目标之前会获得2个以上的工作。
也许服务器过载，无法再接受任何作业。但是，如果您有20台服务器，则每台服务器应该至少可以容纳一台。
也许网络已经饱和，并且客户端和服务器都在其上进行阻止（不太可能在GbE上；可能在100Mb上。）
除非您知道限制因素是开始会话，否则考虑黑客以保持会话打开为时尚早。
它可能是＃1或＃2。从您的日志中摘录。