今年年初的时候，我写了一篇RoR部署方案深度剖析的文章，分析了Rails的进程运行方式下各种部署方案的优缺点，以及采用什么部署方案最优的话题。当时我没有给出具体的性能评测数据，因为我觉得运行的机制原理很清楚的情况下，没有做评测的必要性。但不管怎么说，一份详细的性能评测数据还是更有说服力，因此我很欣喜的看到ShiningRay的这份评测报告有多么宝贵的价值。
浅析Ruby on Rails部署方案
ShiningRay的博客文章
在这份评测报告当中，ShiningRay给出了更多的主流部署方案、详细的分析和丰富的测试数据，可以算是RoR部署方案性能测试之集大成者了。所以没什么好说的，强烈推荐阅读！当然我会建议你在阅读该文档之前，不妨先阅读我在年初写的RoR部署方案深度剖析，会更加有助于你了解ShinningRay的评测报告。
引用一下评测的结论部分：
浅析Ruby on Rails部署方案
ShiningRay的博客文章
在这份评测报告当中，ShiningRay给出了更多的主流部署方案、详细的分析和丰富的测试数据，可以算是RoR部署方案性能测试之集大成者了。所以没什么好说的，强烈推荐阅读！当然我会建议你在阅读该文档之前，不妨先阅读我在年初写的RoR部署方案深度剖析，会更加有助于你了解ShinningRay的评测报告。
引用一下评测的结论部分：
ShiningRay 写道
Lighttpd的三种方案占据了前三位，Lighttpd+FastCGI是性能最高的部署方式。这种方式比另一种流行方案Nginx+Mongrel的方式性能提升了高达50%！FastCGI的好处在此体现出来：
另外Lighttpd相对于Nginx的优势在于请求和响应的接收缓冲区很大，省去多次接收和发送的开销。
Lighttpd+Thin的方式的性能列第三位，这点似乎出乎意料之外，但实际上是因为Lighttpd 1.5支持对HTTP后端建立HTTP KeepAlive链接。在对后端单独的测试中，小并发下的Thin的KeepAlive测试性能并不比FastCGI差，同时Thin实现了非阻塞 IO，而FastCGI则是阻塞式的。相反，HAproxy和Nginx则都不支持HTTP KeepAlive。
而Swiftiply的方式也显示出了强劲的性能，应该是得益于它的“让后端主动连接到Swiftiply”的这种特殊的结构。
当前备受关注的Passenger的部署方式在本案中并没有显示出特别的性能上的优势，不过如果将并发链接数放在300以内，则 Apache2.2/Prefork + Passenger的部署方式的平均每秒响应数上升为204.03，这样看来，倘若为Apache进行一些优化配置，依然不失为一种高效的部署方案。而同时Passenger又是最容易配置的一种方案，能达到这种效果已经非常令人满意。
HAproxy + Mongrel并限制链接数为1，则是一种稳定、保守的部署方式，虽然在这里性能不出众，但是稳定性非常好。
最后，与Nginx相关的三种方案都排在了该榜的末尾，由于Nginx的反向代理负载均衡缺少一些高级的特性以及Rails本身的特性而导致其不适合单独应用在Rails程序的部署上：
- 二进制协议，无需HTTP的解析
- 与前端可以建立持久链接
- 没有锁和上下文切换的开销
另外Lighttpd相对于Nginx的优势在于请求和响应的接收缓冲区很大，省去多次接收和发送的开销。
Lighttpd+Thin的方式的性能列第三位，这点似乎出乎意料之外，但实际上是因为Lighttpd 1.5支持对HTTP后端建立HTTP KeepAlive链接。在对后端单独的测试中，小并发下的Thin的KeepAlive测试性能并不比FastCGI差，同时Thin实现了非阻塞 IO，而FastCGI则是阻塞式的。相反，HAproxy和Nginx则都不支持HTTP KeepAlive。
而Swiftiply的方式也显示出了强劲的性能，应该是得益于它的“让后端主动连接到Swiftiply”的这种特殊的结构。
当前备受关注的Passenger的部署方式在本案中并没有显示出特别的性能上的优势，不过如果将并发链接数放在300以内，则 Apache2.2/Prefork + Passenger的部署方式的平均每秒响应数上升为204.03，这样看来，倘若为Apache进行一些优化配置，依然不失为一种高效的部署方案。而同时Passenger又是最容易配置的一种方案，能达到这种效果已经非常令人满意。
HAproxy + Mongrel并限制链接数为1，则是一种稳定、保守的部署方式，虽然在这里性能不出众，但是稳定性非常好。
最后，与Nginx相关的三种方案都排在了该榜的末尾，由于Nginx的反向代理负载均衡缺少一些高级的特性以及Rails本身的特性而导致其不适合单独应用在Rails程序的部署上：
- 缺少到后台服务器端的链接数限制的能力，这导致了Mongrel在接受大量请求时将时间消耗在上下文切换和锁的争用上。
- 缺乏建立到后台服务器端的持久链接的能力，这导致了在链接的打开、建立、关闭上花费了额外的开销。