关于《浅析Rails部署》

我之前写的文章《浅析Ruby on Rails部署方案》受到不少同学的关注,在此首先感谢大家。

但是也有同学对此提出了一些疑问,我经过检查,发现文章确实存在很多漏洞和不足:

  1. Lighttpd作为负载均衡反向代理时,无论是链接FastCGI还是HTTP后端,KeepAlive链接默认都是关闭的
  2. Nginx的FastCGI模式,默认也是关闭持久链接的
  3. 缺少了一些重要的前后端搭配的方式
  4. 对于Rails应用的内存占用也应该考虑在内

我会针对这一些问题,重新设计测试案例,并重写该文章。再次感谢大家的关注。

浅析Ruby on Rails部署方案

2006初,我接到了公司分配的一个遗留项目,让我负责一个基于C/S的系统的服务器端。其实是系统是基于HTTP协议的,因为负责客户端的同事对于服务器端编程不甚了解,虽然使用PHP对熟悉C++的他来说是驾轻就熟,但是在进一步实现更多的功能和更高的性能上就捉襟见肘了。项目是在非常突然的情况下交给我的,因为该同事在客户端上有更多的事情要做。我在分析了他的数据库结构和PHP源代码之后,决定按照与客户端的通讯协议重写他的服务器端。为了能应付老板苛刻的时间限制,我打算使用正在学习的Ruby on Rails。后来,项目在功能上非常顺利地交付了。

两年过去了,随着客户端数量的不断增加、客户端功能的增加、与服务器端交互数据的增加、老板对功能的要求不断增加,我在这个项目上走了不少弯路,尤其是在部署——或者说是架构——方面。

我遇到的最大的问题就在于并发链接数上。服务器与客户端的每次交互的数据量并不大,但内容无法缓存。起初用的是Nginx/Apache+Mongrel 的部署方式,但当遇到大量并发请求时,常常会遇到Mongrel进程死掉的情况。而客户端的用户在无法登录客户端的时候,经常会反复尝试,加重了服务器的负担、导致最后所有的Mongrel进程都挂掉。

最后,经过不懈努力,在现有的3台低端服务器上,可以满足每天500万次的请求。在这里,我将我的一些心得和研究成果总结出来,与大家分享。


文档地址:http://docs.google.com/Doc?id=ddcvzh74_28f9xppqfh

文章发布在Google Docs上,欢迎大家在其上做批注,有意见和建议也可以在此留言。文章按照知识共享“署名 3.0 中国大陆”许可协议发布,欢迎转载。

Passenger (mod_rails)介绍

Passenger是一个用于Apache2的模块,用它可以方便、高效地部署Rails应用程序。但目前它还只能用于*nix的操作系统。

Passenger的安装十分简单,在装好了Ruby,有Rubygems的系统中输入:

等待安装完成,然后输入:

然后安装程序便会自动查找编译需要的包(g++、Apache、APR、Rake)并进行编译,如果没有找到相应的包,安装程序还会根据操作系统告诉你要执行哪些操作来安装那些包。安装程序完成编译后,它会给出Apache配置中的指令,只需复制到Apache的配置文件中即可。

当Apache加载了Passenger模块后,Passenger会自动检测每个虚拟主机(VirtualHost)的文档根目录(DocumentRoot)是否是一个合格的Rails应用,如果是,那么它就会自动启动Rails的运行时(这个自动检测可以用RailsAutoDetect off指令来关闭)。

其他的指令和问题可以查看用户手册

Passenger的运行机制和Apache的FastCGI比较类似,可以根据请求的数量动态产生Rails的运行时并接受请求,用户可以自己设定产生运行时的最大数量(RailsMaxPoolSize)。

总体上来说,Passenger的部署是所有Rails部署方式中最简单的,而且支持自动产生运行时实例可以解决很多Mongrel方式的并发问题,相信前途是一片光明。如果能直接进入Ubuntu、Gentoo、CentOS、Rpmforge等软件包仓库,那么还能进一步简化他的安装。唯一的缺憾便是它不支持Windows。