我在Docs 中找到了以下内容：Scaling Puppet：
您使用的是默认网络服务器吗？
WEBrick 是用于启用 Puppet 的 Web 服务连接的默认 Web 服务器，它本质上是一个参考实现，并且在超过大约 10 个托管节点之后变得不可靠。在服务于许多节点的任何类型的生产环境中，您应该切换到更高效的 Web 服务器实现，例如Passenger 或 Mongrel。
“十个受管节点”中的数字 10 来自哪里？
我有超过 20 个节点，我可能很快就会有超过 30 个节点。我是否应该更改为乘客？
当您开始遇到 WEBrick 问题时（或稍早一些），您应该更改为Passenger。何时发生这种情况取决于您的工作量。
WEBrick 最大的问题是单线程和阻塞；一旦它开始处理一个请求，它就不能处理任何其他请求，直到它完成第一个请求。因此，对您来说不同的是 Puppet 花费了多少时间来处理请求。
每次客户询问其目录时，这就是一个请求。通过 URL 检索到的每个单独文件puppet:///也是一个请求。如果您轻量地使用 Puppet，则每个目录的生成时间不会太长，您不会在任何给定的 Puppet 运行中分发许多文件，并且每个客户端不会花费超过四到六秒的服务器时间每隔一小时。如果每个客户端每小时花费 4 秒的服务器时间，则 10 个客户端有 5% 的机会发生冲突0——至少一个客户必须等待另一个客户的请求被处理。对于 20 或 30 个客户，这些机会分别为 19% 和 39%。只要每个请求都很短，你就可以忍受一些争用，但是冲突的几率会很快增加，所以如果你有超过 50 个主机（75% 的冲突几率）你真的应该通过使用乘客，除非你正在做积极的性能测量，表明你做得很好。
但是，如果您更努力地使用 Puppet 大师——需要更长时间来生成目录、提供大量文件、提供大文件或其他任何东西——你需要尽快切换到Passenger。我继承了一组大约 30 台主机和一个 WEBrick Puppet master，一切正常，但是当我开始部署新系统时，由新部署（包括几个千兆字节文件1）引起的所有 Puppet 流量都阻止了其他主机从获得他们的更新，所以那是我被迫切换到乘客的时候。
简而言之，如果您没有对 Puppet 做任何过于紧张的事情，您可能会使用 30 个节点，但此时您至少需要监控您的 Puppet Master 的性能，最好还监控您的客户端的更新状态，因此您将知道何时开始运行超出 WEBrick 的功能。
0这是一个标准的生日悖论计算；如果n是客户端的数量，s是每个客户端每小时使用的服务器时间的平均秒数，则在一小时内至少发生一次冲突的机会由 给出1-(s/3600)!/((s/3600)^n*((s/3600)-n)!)。
在任何情况下， 1 Puppet 都不是分发这种大小文件的好方法。我最终切换到将它们放在所有主机都可以访问的 NFS 共享上。
对于 20-30 个节点，应该没有任何问题。请注意，它passenger提供了一些附加功能。为节点提供服务可能会更快，但我不确定如果您只有 30 个节点，您将获得多少改进。
passenger如果您使用超过一百个节点，您应该更改为。当从 puppet-master 请求服务的节点数量达到大约 200 个时，我开始看到问题。在我的情况下，使用默认 Web 服务器，大约 5% 的节点（随机）在每小时运行期间无法接收目录。