在我2016年的Jenkins World 2016演讲结束时，"那么你想要构建世界上最大的Jenkins集群"，我简单地演示了一个拥有100000个并发构建的Jenkins集群，让人们了解Jenkins集群能走多远秤。我的谈话没有任何接近萨夏的基调预算…在那里他们能够开火建立一个由2000多个主机和8000多个并发构建的PSE集群。懒散的读者可能会想知道，我到底是如何实现100000个并发构建的，我到底在玩什么把戏好的，好的，让我们结束这件事…我确实有点作弊，但只在安全的地方所以，如果你想要一个拥有100000个并发构建的Jenkins集群，你需要问自己"我们到底想展示什么？"我能想出两个答案问题：我们是真的很擅长烧钱；詹金斯大师可以应付这种程度的工作量。给定我的预算有限，我只能试着回答第二个问题詹金斯集群能处理100个工作负载，当一个构建在代理上运行时，Jenkins主服务器必须做的大部分工作可以分解为以下内容：流式传输通过远程处理通道从代理发出的控制台日志，并将该日志写入磁盘在生成完成后，通过远程处理通道将所有存档的项目复制到主服务器的磁盘上完成远程代理上的指纹文件生成完成后通过远程处理通道将任何测试报告复制到主服务器的磁盘上集成良好的Jenkins群集还可能包括将上游作业中的构件复制到生成代理的工作区（可能来自群集磁盘中的其他主服务器）触发任何下游作业（可能在集群中的另一个主机上）构建的其余工作负载实际上是在编译和运行测试，等等。这些都发生在生成代理上，对主人。所以只要：代理流式传输回控制台日志（根据我对典型构建的调查，每分钟超过60行）…可能每行输出一行都会刷新I/O，这里会有新文件（带有随机内容来阻止远程处理流压缩）要存档的代理工作区和指纹这里是新的测试结果，每个构建都写入代理工作区，因此我们实际上不需要做真正的建造。所以2014年4月，我创建了Mock Load Builder插件。这个插件允许你定义一个构建步骤，这个步骤在Jenkins主控面前就像一个常规的构建一样……但是不需要在构建上产生几乎那么多的CPU需求探员。不过，当您的目标是100000个并发构建时，即使是Mock Load Builder插件也不够，因为每个构建都会派生一个JVM来执行"Mock"构建。现在，好吧，我们不需要JVM中的大量内存，但它仍然至少是128Mb…当我们有100个内存时，这将增加相当多的RAM，有上千人在同一个地方跑时间。所以我在模拟加载插件fakeMockLoad中添加了另一层模拟，通过这个系统属性设置，模拟负载实际上将直接在代理JVM上生成，而不是在从代理派生的JVM中生成JVM。我们仍然在生成相同的控制台日志、构建构件、测试报告，等等，只是现在我们不需要为另一个JVM付费。唷，那是13 TB的内存拯救了。但是等等…每个构建代理都将使用至少512Mb的RAM…超过50Tb的RAM…或者25个x1.32xlarge AWS实例…对于只针对代理的随需应变实例来说，几乎是350美元/小时…另外，这些并不是真正的工作…除了标题之外，我们没有什么可以展示的数字。好吧作为在我对JNLP4协议进行负载测试的一部分，我编写了一个测试客户机，它可以从同一个JVM设置至少4000个JNLP连接，也许我们可以使用它的一个修改版本来将JNLP构建代理多个在同一个JVM上……主机上的工作负载是由有多少个远程处理通道和有多少数据在其中的函数决定的通过那些频道发送的…结果是用一个特殊的多天线远程处理.jar我可以在每c4.8XL上使用fakeMockLoad运行近10000个构建代理。在1.675美元/小时，这是一个更合理的16美元/小时…加上更好的，我们有更少的机器设置-起来。一切都好在我的星群里其他的都是真实的。500个真正的主机（运行在分装在x1.32xlarge和一对c4.8xlarge之间的Docker容器中）和CloudBees-Jenkins操作中心（在专用c4.xlarge上裸体运行）。如果我将这些主机分散到一个小空间中，我会受到磁盘空间的限制，如果我将这些主机分散到一个较小的空间中与其尝试在同一个x1.32xlarge上塞进400个主机，我可以让集群运行超过90次几分钟。那里是在我演讲之前，我记得在启动集群时拍摄的一段视频。当时有两台生成代理计算机的磁盘空间不足，这就是为什么我检查的主机正在运行大约160个并发生成每个.TL我博士有一个Jenkins集群（总共90分钟），每个主机有500个主机，每个主机有200个构建代理（每个主机），总的并发构建率为100000个并发构建。是的，在我可用的预算内保持集群运行是有问题的。是的，维护一个具有如此数量的并发构建的系统是有挑战性的。是的，我确实做了些骗人的事。但是Jenkins masters和Jenkins集群可以处理这些工作负载，前提是您首先拥有实际支持工作负载的硬件！