浏览 5135 次
锁定老帖子 主题:推荐一篇很好的RoR部署方案性能评测
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2008-07-08
RoR部署方案深度剖析的文章,分析了Rails的进程运行方式下各种部署方案的优缺点,以及采用什么部署方案最优的话题。当时我没有给出具体的性能评测数据,因为我觉得运行的机制原理很清楚的情况下,没有做评测的必要性。但不管怎么说,一份详细的性能评测数据还是更有说服力,因此我很欣喜的看到ShiningRay的这份评测报告有多么宝贵的价值。
今年年初的时候,我写了一篇浅析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程序的部署上:
声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2008-07-09
很好的文章,看完学习到了很多东西,感谢推荐!
|
|
返回顶楼 | |
发表时间:2008-07-09
要我选,我会选nginx+apache(mod_passenger), apache(mod_passenger)退化成一个rails集群.可能mongrel没想像中的那么好,不过mod_passenger真的很棒.
|
|
返回顶楼 | |
发表时间:2008-07-09
swachian 写道 要我选,我会选nginx+apache(mod_passenger), apache(mod_passenger)退化成一个rails集群.可能mongrel没想像中的那么好,不过mod_passenger真的很棒.
真的不觉得mod_rails有那么的好,apache最大的问题在于内存消耗量和并发,你这样的配置对硬件来说更是雪上加霜 |
|
返回顶楼 | |
发表时间:2008-07-11
https://docs.google.com/View?docid=ddcvzh74_28f9xppqfh,这个地址怎么访问不了了
|
|
返回顶楼 | |
发表时间:2008-07-13
用https访问就可以了
|
|
返回顶楼 | |
发表时间:2008-07-14
喜欢这样的文章
|
|
返回顶楼 | |