RoR部署方案深度剖析

我想补充下，其实http proxy的这种转发，类似路由器的的转发功能，所以内网的机器可以做成服务器。 就像我可以把javaeye安装在家里面的一个机器上。当然你路由器拨号获取的是一个动态真实ip, 用花生壳类似的服务，可以绑定到你的域名上。这里的前端  web 服务器 和 后面的处理动态请求的服务器应该是类似的应用。


目前我用的是 InstantRails ，这个比较傻瓜式的，类似easyPHP. 就是  apache+Mongrel

我的主业是搞j2ee的，不过没有看到 类似这种集成了的 apache+tomcat,  

rubyonrails 官方网站是用mongrel_cluster + Apache 2.2，是另一种选择的一个例证：
http://weblog.rubyonrails.org/2006/6/11/rails-system-back-on-track

虽然他的访问量比JE大2-3倍，不过似乎用到RAILS的地方只是那个BLOG，动态请求的地方估计没有JE那么频繁(BLOG的缓存也容易做)。

不错，这些是关键，而且，robbin似乎没有提mongrel_cluster（也许觉得没必要），其实这个东西才真正让mongrel方案变得可行，linux我也用了很久（虽然不能和robbin比），但是能够把精力节省出来放在业务上当然更好了，我觉得nginx/mongrel_cluster是一个比较平衡的策略，部署十分简单，基于debian/ubuntu系很容易就搞定了，而且因为采用http proxy，以后水平扩展也很简单，动态部分proxy，静态资源用nfs，一般有点基础的半天就能入门，这样可能效率的确不如lighttpd/fastcgi，但是也算是次优了......

Mongrel官网上的一篇文章：

http://mongrel.rubyforge.org/docs/apache.html

讲述了 apache+mongrel 的部署方式。 上面还提及了apache的 mod_proxy_balancer 模块。
大家可以参考一下。

:D

mongrel_cluster的功能很简单，就是控制n个mongrel实例启动关闭重起，自己写个类似的shell脚本，不过十几行代码。比方说JavaEye网站现在FastCGI应用服务器群集的启动关闭重起，也是我写的shell脚本，也许可以命名为fastcgi_cluster了，呵呵。Lighttpd+FastCGI水平扩展的方式和HTTP Proxy是一样的，唯一不同的就是一个走HTTP协议，一个走FastCGI协议。

robbin提到了服务器到用户端的数据传输，我再补充一下用户端到服务器的数据传输：


我们知道 IO 相对于 cpu 是很慢的，在 linux 上 lighttpd 使用了epoll，解决的大并发慢速链接的问题。
那么，在有很多用户同时上传大文件的时候，lighttpd 是怎么处理的呢？上面的资料解释了这个问题：在
有很多慢速上行数据时，lighttpd 将数据接收完毕后才会发送给backend，这样的话 backend 就不会被一
个慢速请求占用，可以服务更多的请求。nginx 也有类似的设计。Mongrel 不清楚。

我使用 php 的时候，一直倾向于 apache + mod_php，了解了 lighttpd 的上述功能后，打算试试
lighttpd + php_fastcgi， 估计性能会有大幅的提高。

我还真的没有注意到这个问题，刚才研究了一下，发现Lighttpd的确做的很棒！具体的过程是这样的：

Lighttpd在接收到POST请求以后，会在硬盘的/var/tmp目录下面创建相应的临时文件，每个临时文件最大1MB，如果POST请求超过1MB，会创建更多的硬盘临时文件。在处理整个文件上传的过程中，Lighttpd都不会和FastCGI打交道，即使你杀掉FastCGI进程，文件上传过程也不会受什么影响。

当Lighttpd完整的收下来整个POST数据以后，才会将数据推给FastCGI进程去处理。

因此，当上传大文件，整个上传过程无论多慢，都只是Lighttpd在处理，并不会影响到FastCGI进程。但是如果黑客刻意上传非常大的文件，比如说1GB的大文件，当Lighttpd完整的接受下来以后，还是会一股脑推给FastCGI，导致FastCGI的内存暴涨。要解决这个问题，可以在Lighttpd端设置request的最大限制，例如：



设置为10MB，这样黑客要伪造POST提交，最大只允许10MB，就可以解决问题了。