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

【问题标题】：Is it advantageous to have multiple build agents on the same machine?在同一台机器上拥有多个构建代理是否有利？
【发布时间】：2015-05-26 10:14:42
【问题描述】：

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

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

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

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

但是，如果在构建期间还存在大量磁盘活动，也许一个代理正在使用可用的 CPU 周期，而另一个代理正在访问磁盘？

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

【问题讨论】：

标签： tfsbuild

【解决方案1】：

正如 Daniel 已经提到的，这取决于，但通常，如果您的代理正在执行普通构建，那么拥有多个代理将允许您并行运行多个构建。这样做时，IO 和内存限制可能会导致您的构建服务器出现问题，某些防病毒产品也是如此。

如果您构建的服务器配备了快速的本地存储（虚拟机的 RAM 磁盘、物理 SSD 或物理驱动器优先于构建工作区的 SAN 存储）并且分配了足够的 CPU 内核，它可能能够运行相当多的并行构建。

如果已配置，MsBuild 和 Team Build 都可以将构建多个解决方案、项目和/或配置的负载分散到多个代理上，从而大大缩短构建解决方案所需的时间。（只要硬件能跟得上这个）。

除此之外：同样，当您的硬件跟不上时，在不同的服务器上拥有多个代理可以让您将构建横向扩展（相对于纵向扩展）到这些多个代理，从而减少总体构建时间那样。

特别是当您配置了 CI 构建并且您的构建时间超过几分钟时，拥有多个代理对开发团队是有益的，这样他们的构建并行运行并且所有开发人员都能更快地获得他们的反馈。如果您只有一个构建代理，您的开发人员将不得不相互等待完成。

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

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

【讨论】：

感谢您的详细解答。我们正在构建简单的解决方案，尽管我们的 TFS 构建服务器目前托管在 NetApp SAN 上的 VMware 中。它可能会转移到一个应该明显更快的 Tintri 存储平台。我认为我能做的最好的事情就是尝试一下，看看它有什么不同（如果有的话）。

【解决方案2】：

与许多事情一样，答案是“取决于”。

看看我们是如何做到的：我们在机器上最多有 4 个构建代理来简单地构建解决方案，我们可能会更高，我们也有运行 PowerShell 脚本来做各种事情的代理（相同的机器），所以真的相比之下，它是轻量级的，并且不会对运行 CI 构建的代理造成问题。一个机器上的几个代理很好（没有什么强大的，双核就是全部），我还没有看到由同时运行几个构建的服务器导致任何真正的负面性能。

但是，对于数据库构建等其他事情，我们在服务器上只有一个代理，否则我们会在构建/部署之前恢复锁定和各种其他问题。

如果您要最大化或锁定任何资源，那么您可能希望在每台服务器上坚持使用一个构建代理，但是我会说“试一试”，然后您可能会发现，最好有一个稍微当你有一个构建队列时，构建时间会更长，但它会更快地浏览你的构建列表。

【讨论】：

感谢您的回答，我想我会按照您的建议尝试一下，然后比较两个配置的结果。