2007-07-06
RoR的部署方案选择
RoR的部署方式从架构上来说分为前端和后端:
一、前端
前端的作用就是处理静态资源,将动态请求分发到后端,有时候也带有一些额外的功能,例如对特定URL进行rewrite和redirect,对HTTP输出进行gzip压缩等等。
前端目前已知的可以选择apache, lighttpd, litespeed, nginx, haproxy
1、apache2.2
apache是全球市场占有率最高的web server,超过全球互联网网站50%的网站都用apache。apache2.2 + mod_proxy_balancer是一个非常流行,非常稳定的方案。
使用apache2.2唯一的问题就是apache的性能和后面那些轻量级web server相比,差太远了。一方面在处理静态请求方面apache要比lighttpd慢3-5倍,内存消耗和CPU消耗也高出一个数量级,另一方面mod_proxy_balancer的分发性能也不高,比haproxy差很远。
2、lighttpd
lighttpd是一个轻量级高性能web server,一个在MySQL Inc工作的德国人写的。性能很好,内存和CPU资源消耗很低,支持绝大多数apache的功能,是apache的绝好替代者。目前lighttpd已经上升到全球互联网第四大web server,市场占有率仅此于apache,IIS和Sun。
lighttpd唯一的问题是proxy功能不完善,因此不适合搭配mongrel来使用。lighttpd下一个版本1.5.0的proxy模块重写过了,将会解决这个问题。
3、litespeed
和lighttpd差不多,商业产品,收费的。比lighttpd来说,多一个web管理界面,不用写配置文件了。litespeed专门为单机运行的RoR开发了一个lsapi协议,号称性能最好,比httpd和fcgi都要好。他的proxy功能比lighttpd完善。
litespeed的缺点我却认为恰恰是这个lsapi。因为lsapi不是web server启动的时候启动固定数目的ruby进程,而是根据请求繁忙程度,动态创建和销毁ruby进程,貌似节省资源,实则和apache2.2进程模型一样,留下很大的黑客攻击漏洞。只要黑客瞬时发起大量动态请求,就会让服务器忙于创建ruby进程而导致CPU资源耗尽,失去响应。
当然,litespeed也支持httpd和fcgi,这个和lighttpd用法一样的,到没有这种问题。
4、nginx
一个俄国人开发的轻量级高性能web server,特点是做proxy性能很好,因此被推荐取代apache2.2的mod_proxy_balancer,来和mongrel cluster搭配。其他方面和lighttpd到差不多。
要说缺点,可能就是发展的时间比较短,至今没有正式版本,还是beta版。没有经过足够网站的验证。
5、haproxy
就是一个纯粹的高性能proxy,不处理静态资源的,所有请求统统分发到后端。
二、后端
后端就是跑ruby进程,处理RoR动态请求了。运行后端ruby进程有两种方式:
1、fcgi方式
准确的说,不能叫做fcgi方式,其实就是启动一个ruby进程,让这个ruby进程监听一个tcp/unix socket,以fcgi协议和前端通讯。所以fcgi不是指ruby进程的运行方式,而是ruby进程使用的通讯协议。这就好比你tomcat可以用http也可以使用ajp通讯一样,tomcat自己的运行方式都一样的,只是通讯方式不一样。
fcgi方式启动ruby进程,可以使用lighttpd带的一个spawn-fcgi工具来启动(JavaEye目前采用这种方式)。
值得一提的是,apache2.2的mod_fastcgi的方式和上面还不太一样,由apache动态创建fcgi进程和管理fcgi进程,这种方式和litespeed的lsapi面临的问题是一样的,此外apache的mod_fastcgi自己也有很多严重的bug,是一种很糟糕的部署方式。这种糟糕的部署方式也败坏了fcgi的名声。
fastcgi只是一种协议,虽然古老,但并不是不好用,http协议也很古老。没有必要因为apache的mod_fastcgi的运行方式的问题而连带把fastcgi都一同否定了。fastcgi只是一个协议(程序之间的语言),是apache的mod_fastcgi这个模块有问题。打个比方,有个人英语水平很差,和你用英语对话,总是结结巴巴的,那你说是英语(fastcgi)这种语言有问题呢?还是和你对话的这个人(mod_fastcgi)有问题呢?
2、http方式
也就是用mongrel去跑ruby进程,由于mongrel实际上已经是一个简单的http server,所以也可以单独作为web server使用。mongrel现在越来越受欢迎了。
用fcgi方式还是http方式,我个人觉得区别不大,关键还是看应用的场合,一般而言,推荐的搭配是:
lighttpd + fcgi 或者 nginx +mongrel,而apache因为性能差距,而不被推荐。
JavaEye为什么用lighttpd + fcgi呢?原因如下:
1) lighttpd发展了好几年了,市场占有率也相当高,是一个经过实践检验的server,它的文档也很全;而nginx还没有经过足够的市场检验,文档也很缺乏
2) JavaEye的ruby进程和web server在一台机器上面跑,通过unix socket使用fcgi协议通讯可以避免tcp的网络开销,其通讯速度比使用tcp socket使用http协议通讯要快一些。
什么场合使用haproxy?
大规模部署,例如你的RoR应用到十几台服务器上面去,你用haproxy会更好,可以方便的添加删除应用服务器节点,proxy性能更好。
一、前端
前端的作用就是处理静态资源,将动态请求分发到后端,有时候也带有一些额外的功能,例如对特定URL进行rewrite和redirect,对HTTP输出进行gzip压缩等等。
前端目前已知的可以选择apache, lighttpd, litespeed, nginx, haproxy
1、apache2.2
apache是全球市场占有率最高的web server,超过全球互联网网站50%的网站都用apache。apache2.2 + mod_proxy_balancer是一个非常流行,非常稳定的方案。
使用apache2.2唯一的问题就是apache的性能和后面那些轻量级web server相比,差太远了。一方面在处理静态请求方面apache要比lighttpd慢3-5倍,内存消耗和CPU消耗也高出一个数量级,另一方面mod_proxy_balancer的分发性能也不高,比haproxy差很远。
2、lighttpd
lighttpd是一个轻量级高性能web server,一个在MySQL Inc工作的德国人写的。性能很好,内存和CPU资源消耗很低,支持绝大多数apache的功能,是apache的绝好替代者。目前lighttpd已经上升到全球互联网第四大web server,市场占有率仅此于apache,IIS和Sun。
lighttpd唯一的问题是proxy功能不完善,因此不适合搭配mongrel来使用。lighttpd下一个版本1.5.0的proxy模块重写过了,将会解决这个问题。
3、litespeed
和lighttpd差不多,商业产品,收费的。比lighttpd来说,多一个web管理界面,不用写配置文件了。litespeed专门为单机运行的RoR开发了一个lsapi协议,号称性能最好,比httpd和fcgi都要好。他的proxy功能比lighttpd完善。
litespeed的缺点我却认为恰恰是这个lsapi。因为lsapi不是web server启动的时候启动固定数目的ruby进程,而是根据请求繁忙程度,动态创建和销毁ruby进程,貌似节省资源,实则和apache2.2进程模型一样,留下很大的黑客攻击漏洞。只要黑客瞬时发起大量动态请求,就会让服务器忙于创建ruby进程而导致CPU资源耗尽,失去响应。
当然,litespeed也支持httpd和fcgi,这个和lighttpd用法一样的,到没有这种问题。
4、nginx
一个俄国人开发的轻量级高性能web server,特点是做proxy性能很好,因此被推荐取代apache2.2的mod_proxy_balancer,来和mongrel cluster搭配。其他方面和lighttpd到差不多。
要说缺点,可能就是发展的时间比较短,至今没有正式版本,还是beta版。没有经过足够网站的验证。
5、haproxy
就是一个纯粹的高性能proxy,不处理静态资源的,所有请求统统分发到后端。
二、后端
后端就是跑ruby进程,处理RoR动态请求了。运行后端ruby进程有两种方式:
1、fcgi方式
准确的说,不能叫做fcgi方式,其实就是启动一个ruby进程,让这个ruby进程监听一个tcp/unix socket,以fcgi协议和前端通讯。所以fcgi不是指ruby进程的运行方式,而是ruby进程使用的通讯协议。这就好比你tomcat可以用http也可以使用ajp通讯一样,tomcat自己的运行方式都一样的,只是通讯方式不一样。
fcgi方式启动ruby进程,可以使用lighttpd带的一个spawn-fcgi工具来启动(JavaEye目前采用这种方式)。
值得一提的是,apache2.2的mod_fastcgi的方式和上面还不太一样,由apache动态创建fcgi进程和管理fcgi进程,这种方式和litespeed的lsapi面临的问题是一样的,此外apache的mod_fastcgi自己也有很多严重的bug,是一种很糟糕的部署方式。这种糟糕的部署方式也败坏了fcgi的名声。
fastcgi只是一种协议,虽然古老,但并不是不好用,http协议也很古老。没有必要因为apache的mod_fastcgi的运行方式的问题而连带把fastcgi都一同否定了。fastcgi只是一个协议(程序之间的语言),是apache的mod_fastcgi这个模块有问题。打个比方,有个人英语水平很差,和你用英语对话,总是结结巴巴的,那你说是英语(fastcgi)这种语言有问题呢?还是和你对话的这个人(mod_fastcgi)有问题呢?
2、http方式
也就是用mongrel去跑ruby进程,由于mongrel实际上已经是一个简单的http server,所以也可以单独作为web server使用。mongrel现在越来越受欢迎了。
用fcgi方式还是http方式,我个人觉得区别不大,关键还是看应用的场合,一般而言,推荐的搭配是:
lighttpd + fcgi 或者 nginx +mongrel,而apache因为性能差距,而不被推荐。
JavaEye为什么用lighttpd + fcgi呢?原因如下:
1) lighttpd发展了好几年了,市场占有率也相当高,是一个经过实践检验的server,它的文档也很全;而nginx还没有经过足够的市场检验,文档也很缺乏
2) JavaEye的ruby进程和web server在一台机器上面跑,通过unix socket使用fcgi协议通讯可以避免tcp的网络开销,其通讯速度比使用tcp socket使用http协议通讯要快一些。
什么场合使用haproxy?
大规模部署,例如你的RoR应用到十几台服务器上面去,你用haproxy会更好,可以方便的添加删除应用服务器节点,proxy性能更好。
评论
现在的网站,既有系统想运行再tomcat上,新开发的功能准备运行在rails上。请问有没有好的方式让tomcat和mongrel/webrick结合到apache中?
2) JavaEye的ruby进程和web server在一台机器上面跑,通过unix socket使用fcgi协议通讯可以避免tcp的网络开销,其通讯速度比使用tcp socket使用http协议通讯要快一些。
这也写出来,谁不知道unix socket与TCP,UDP一点关系都没有。
这也写出来,谁不知道unix socket与TCP,UDP一点关系都没有。
Robbin推荐的Ror的搭配,和Apache+JBoss+MySQL的搭配比较性能如何呢?
我们公司产品(SAAS)一直是这样的搭配,前面用LVS做LB。性能大约是单台Server在30个并发的情况下,响应时间平均在3s左右。(双核至强1.6、2G、Ubuntu)
我们公司产品(SAAS)一直是这样的搭配,前面用LVS做LB。性能大约是单台Server在30个并发的情况下,响应时间平均在3s左右。(双核至强1.6、2G、Ubuntu)
harrison.yao
2007-07-07
回复
好文章!推荐多做一些关于ROR高性能部署环境的帖子,大家一起研究学习,感谢!
发表评论
我的相册
94届浮雕留影.jpg
共 44 张
共 44 张
最近加入圈子
链接
最新评论
-
网络招聘是如何被做烂掉的 ...
51JOB很烂!而且他和很多外驻公司挂钩!我再也不用51JOB!
-- by xxrrss -
中国行业应用软件领域恶性 ...
这就是中国国情,其实不单是IT行业软件这一领域,中国的其他行业不也是如此?人不能 ...
-- by wq11 -
Facebook的成功秘诀是什么 ...
robbin认为校内的做法愚蠢,但我认为校内不重视开发者,有它自己的原因。rob ...
-- by include -
中国行业应用软件领域恶性 ...
是这么回事,我们是做银行的,挺苦的啊:)不过比前几年好点了,水稍微清点了
-- by zhdy007 -
中国行业应用软件领域恶性 ...
icewubin 写道引用to icewubin, “与国外没有办法比”不等于研 ...
-- by jacklondon







评论排行榜