推荐一篇很好的RoR部署方案性能评测
程序员文章站
2022-03-08 20:17:16
...
今年年初的时候,我写了一篇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在接受大量请求时将时间消耗在上下文切换和锁的争用上。
- 缺乏建立到后台服务器端的持久链接的能力,这导致了在链接的打开、建立、关闭上花费了额外的开销。