引用
Lighttpd+FastCGI > Lighttpd+Mongrel > Nginx+Mongrel > Apache+Mongrel > Ngignx+FastCGI > Apache+FastCGI
其中Lighttpd+FastCGI是性能最佳方案，而Apache+FastCGI是性能最差方案。
有些细心的同学可能会产生一个新的疑问？你说到底，之所以Lighttpd跑RoR性能最好，还是在于Lighttpd接收数据不限定缓冲区的大小，而Apache/Nginx限定了缓冲区大小所至。那为什么Nginx要限制呢？Lighttpd如果不限制的话，会不会导致Lighttpd内存爆掉？
Nginx限制Proxy Buffer Size其实也有道理，因为Nginx并不是为RoR量身打造的Web服务器，Nginx最广泛的用途还是高负载大访问量的代理服务器，在Nginx主要的应用场合，如果不做这样的限制，那Nginx端的资源消耗就相当高了，有可能会拖累所代理的服务速度。
Lighttpd主要用途之一就是提供高性能的FastCGI支持的Web服务器，所以必须为FastCGI量身打造。Lighttpd端承担的负载越高，就越能有效的加快FastCGI执行速度。其实我们稍微心算一下，假设Lighttpd后面挂1000个FastCGI进程，每个FastCGI进程同时送过来50KB的页面数据，Lighttpd就是全部吃下来，也不过只消耗50MB的内存而已，而事实上1000个FastCGI进程足以支撑每日上千万的大网站了。
只有当我们使用服务器端程序控制大文件下载的时候，有可能造成Lighttpd内存暴涨，例如某个用户使用100个线程并发下载JavaEye圈子的共享文件，在没有特殊处理的情况下，Lighttpd将全部吃下100个FastCGI进程送过来的10MB数据，就会立刻暴涨1GB的内存。这种情况怎么办呢？其实我们也有办法让Lighttpd一点内存都不吃， 请看我写的另外一篇文章：RoR网站如何利用lighttpd的X-sendfile功能提升文件下载性能
可能很多人看了我的文章，对结论觉得很诧异，既然Lighttpd+FastCGI这样好，为什么那么多人都推崇Mongrel，否定FastCGI呢？我想，不外乎几个原因：
一、Lighttpd+FastCGI配置起来比较专业，而Mongrel配置简单
尽管我当初第一次搭建Lighttpd+FastCGI环境没费什么周折，但是我观察到非常多的Ruby程序员很难成功搭建一个Lighttpd+FastCGI的环境出来，很多人连Lighttpd都无法独立的运行起来。这也许是因为很多程序员习惯了Windows开发环境，对于Unix上面通过源代码编译安装的方式过于陌生造成的。而我从97年开始使用Unix，至今已有10年历史，因此搭建这样简单的系统，对我来说不造成什么障碍。
而Mongrel就简单了，gem install mongrel安装完毕，mongrel_rails start启动，哪个人不会？毕竟绝大多数开发人员和部署人员不是高手，他们熟悉哪种方式，自然就会推崇哪种方式。
二、Mongrel可以独立作为Web服务器运行，开发环境和部署环境统一
一般来说，程序员肯定是尽量保持开发环境和部署环境的一致性，避免部署到生产环境出现不测的后果。既然在开发环境熟悉了Mongrel，当然更加愿意在生产环境使用Mongrel，而不愿意碰没有接触过的Lighttpd。
三、Mongrel支持HTTP协议，因此不论监控还是集成其他服务都比较简单，容易玩出更多的花活。
HTTP协议要比FastCGI协议普及的多，因此通过HTTP方式的监控工具，群集管理工具，集成其他服务的工具都是一抓一大把。而支持FastCGI的第三方工具就少得可怜了。你要玩很多花活出来，用FastCGI的话，就难免得自己开发相应的工具，那当然不如使用Mongrel方便啦。
最后，如果你看了这篇文章，想摩拳擦掌的安装一把Lighttpd+FastCGI的话，那么我的这篇文章就是最好的安装指南：
在Linux平台上安装和配置Ruby on Rails详解