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