我理解Puma相对于其他Rails Web服务器的好处是它如何处理慢速客户端。当Puma服务器接收并下载（可能很慢）请求时，它仍然可以接收和下载可能更快下载的其他请求，并在慢速请求收到之前传递给工作人员进行处理。
但我找不到任何有关此限制的信息（如果有的话）。
Puma可以同时下载任意数量的请求吗？如果1000个慢速请求同时命中它，那么第1001个请求是否会首先到达Puma工作者，假设它不是一个缓慢的请求？
我想我一般感兴趣的是多个慢速请求对其他请求的影响，包括彼此 - 因为我正在处理一个可能涉及大量'慢请求'的应用程序（来自手机的图像上传）通过3G）。
@ nate-berkopec的This great article原则上有助于解释Puma如何帮助慢客户端：“在集群模式下，Puma可以处理缓慢的请求（感谢单独的主进程，其责任是下载请求并传递它们）...“任何人都可以放下的任何光线都会非常受欢迎。
答案 0 :(得分：2)
有许多注意事项，例如IO轮询系统，内存和并发问题。
据我所知，Puma使用select系统调用（与碘或乘客不同，它也可以保护您免受慢速客户端的攻击，但使用kqueue或epoll）。
select系统调用在大多数系统上受限制（通常最多1024个客户端/ maxfd）。我认为会产生限制。
但是，我知道Puma正在努力用可移植和有效的方式替换select系统调用（例如利用nio4r gem）。
我不知道这是否已经实现，但它会打破这个限制并可能提高性能。
慢速客户端仍会消耗内存，因为它们会缓慢填充缓冲区中的标头数据，或者慢慢下载已发送的缓冲数据（将缓冲区保留在内存中直到下载完成）。
内存限制总是会增加客户端处理速度的限制。
可以提升一些限制，例如使用X-Sendfile发送静态文件（支持碘，当Puma或乘客在nginx下运行时）......但这不是你可以解决的问题。
Puma处理Ruby的GIL（全局指令锁）中的慢客户端。这意味着当Puma处理慢速客户端时，没有其他线程/指令可以执行。
这通常不是问题，但是足够多的慢客户端会增加上下文切换和系统调用的成本。这可能（可能）大大减慢服务器速度。
Passenger和iodine都在GIL之外执行缓慢的客户端缓冲，允许这些系统调用真正并发（当有多个CPU核心可用时）。
这将缓解问题但不能完全解决问题。
最大的问题通常是IO轮询系统。对此的解决方案是Puma的路线图（可能已经实施，我不确定）。
其他问题（内存限制和并发限制）相对不太重要，但如果不使用语言扩展就不能减轻它们（碘服务器用C语言编写，而Passenger用C ++编写）。
由于Puma（目前）不需要任何语言扩展（除了它在C和Java中集成的HTTP解析器），这些问题仍然存在。
我应该指出我是碘HTTP / Websocket服务器的作者，所以我有点偏颇。