2008-07-08
推荐一篇很好的RoR部署方案性能评测
今年年初的时候,我写了一篇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在接受大量请求时将时间消耗在上下文切换和锁的争用上。
- 缺乏建立到后台服务器端的持久链接的能力,这导致了在链接的打开、建立、关闭上花费了额外的开销。
评论
RobinWu
2008-07-14
喜欢这样的文章
robbin
2008-07-13
用https访问就可以了
kiol
2008-07-13
是啊,文章看不了了
wjd2002
2008-07-11
neodoxy
2008-07-09
swachian 写道
要我选,我会选nginx+apache(mod_passenger), apache(mod_passenger)退化成一个rails集群.可能mongrel没想像中的那么好,不过mod_passenger真的很棒.
真的不觉得mod_rails有那么的好,apache最大的问题在于内存消耗量和并发,你这样的配置对硬件来说更是雪上加霜
swachian
2008-07-09
要我选,我会选nginx+apache(mod_passenger), apache(mod_passenger)退化成一个rails集群.可能mongrel没想像中的那么好,不过mod_passenger真的很棒.
coolhair
2008-07-09
很好的文章,看完学习到了很多东西,感谢推荐!
发表评论
提醒: 该博客已发表在公共论坛,博客所有留言会成为论坛回贴,留言请注意遵守论坛发贴规则
- 浏览: 1944632 次
- 性别:

- 来自: 上海

- 详细资料
搜索本博客
我的相册
iphone2.jpg
共 39 张
共 39 张
最近加入圈子
链接
最新评论
-
中国行业应用软件领域恶性 ...
to icewubin, “与国外没有办法比”不等于研发0投入。 ====> 没 ...
-- by jacklondon -
中国行业应用软件领域恶性 ...
大家根本不用担心行业问题,这个现象在任何行业都是存在的,而且是稳定持续性发展,就 ...
-- by 龙泽风 -
中国行业应用软件领域恶性 ...
感觉应该想点办法改变一下现状才行
-- by guoyankun -
中国行业应用软件领域恶性 ...
“与国外没有办法比”不等于研发0投入。
-- by icewubin -
中国行业应用软件领域恶性 ...
汽车行业就不要说了,上海的汽车行业更不要说了。国内汽车行业的技术力量,特别是设计 ...
-- by jacklondon






评论排行榜