在同一台机器上有多个构建代理是否有利？

Question

我们正在使用Team Foundation Build，目前只有一个构建代理。

如果我们在同一台机器上配置第二个构建代理，当我们有一个构建队列完成时，这会给我们带来性能好处吗？

请注意，我们是而不是使用代理标记，因此我们所有的构建都可以发送到两个代理之一。

如果构建主要是CPU密集型任务，我很难看到在并行构建中将会有显着的优势，因为构建队列的总处理器时间将保持不变，而不管哪个代理构建它。

然而，如果也有构建过程中显著的磁盘活动，也许一个代理可以利用可用的CPU周期，而另一代理访问磁盘？

有an MSDN article是提到不同的构建拓扑，这确实有在某些情况下在同一台机器上的多个生成代理。然而，目前还不清楚这是否仅仅是因为代理商有不同的标签。

Answer 1

对于很多事情，答案是“是靠”。看看我们如何做到这一点：我们在机器上最多有4个构建代理，这些代理只是构建解决方案，我们可能会更高，我们也有运行PowerShell脚本来执行各种事情的代理（同一台机器），所以相比之下非常轻量级，并且不会对运行CI构建的代理造成问题。在一个盒子上的几个代理是好的（没有什么强大的，双核心都是），我还没有看到由服务器同时运行几个版本造成​​的任何真正的负面表现。

然而，与其他的东西，如数据库的构建，我们只有一台服务器上的一个代理，否则我们得到锁和建设之前恢复各种其他问题/部署。

如果你正在最大化或锁定任何资源，那么你可能想要坚持每个服务器的一个构建代理，但是我会说“给它一个去”，看看，你可能会发现最好有一个当你有一排排排队时，建造时间会稍微长一些，但它会更快地啃咬你的建造列表。

Answer 2

正如丹尼尔已经提到，这取决于，但一般来说，如果你代理是做普通的版本，然后有多个代理将允许你运行多个构建并行。这样做时，IO和内存限制可能会在您的构建服务器上导致问题，特定的反病毒产品也可能会造成问题。

如果您构建的服务器配备了快速本地存储（对于构建工作区，虚拟机的物理SSD或物理驱动器优先于SAN存储）并且分配了足够的CPU内核，因此可以运行相当很少有并行的构建。

如果配置的MSBuild和团队建设都可以传播构建多个解决方案，项目和/或配置在多个代理，才能建立您的解决方案的时候造成巨大的改进的负载。 （只要硬件能够跟上这一点）。

旁白：按照同样的思路，当你的硬件跟不上，具有不同服务器上的多个代理，您可以将构建横向扩展（VS规模达）对这些多个代理，降低了整体的构建这样的时间。

尤其是当你有一个CI构建配置您的构建超过几分钟的时间较长，这是对开发团队有利于有多个代理，其建立在并行运行的方式和所有开发商获得他们的反馈更快。如果你只有一个构建代理，它会导致你的开发人员不得不等待对方完成。

确实有一些情况下，多个代理对你没有任何好处。这些通常是特例：

• 您的构建代理兼作“部署代理”，运行将您的产品安装到服务器本身的脚本。在实验室管理环境中，这些代理很常见。
• 您的构建定义需要读取或写入共享资源（例如，通用固定文件目录）。多个代理会争夺这一点，并可能导致破解构建的文件锁定。
• 您的服务器一般资源不足（内存或磁盘IO），并且无法同时处理多个构建版本。
• 您的网络带宽非常低，在下载源文件或将生成结果保存到服务器或文件共享时，并行运行多个版本可能会导致超时和其他问题。大多数这些项目可以通过更多的内存，本地存储或更多带宽来解决，并且限制代理的数量可能只是暂时的。
• 当你只有一个构建定义，它是一个门控构建。在这种情况下，Team Build将始终按顺序运行构建。如果您有多个具有不同工作区配置的门控版本，那么拥有多个代理是有益的。