作者：Robbin 来源：JavaEye 酷勤网收集 2008-03-11
摘要
1、当使用mongrel的时候，如果下载文件很大，会导致mongrel内存暴涨！2、当使用fcgi的时候，如果前端Web服务器没有足够大buffer，会导致fcgi进程被挂住；3、即使使用lighttpd+fcgi，也会对服务器造成不小的性能开销。
传统的Web服务器在处理文件下载的时候，总是先读入文件内容到应用程序内存，然后再把内存当中的内容发送给客户端浏览器。这种方式在应付当今大负载网站，音频视频网站力不从心。sendfile是现代操作系统支持的一种高性能网络IO方式，操作系统内核的sendfile调用可以将文件内容直接推送到网卡的buffer当中，从而避免了Web服务器读写文件的开销，实现了“零拷贝”模式。
作为最流行的轻量级Web服务器的翘楚，lighttpd提供了良好的sendfile支持，JavaEye网站服务器使用的就是lighttpd。在Linux操作系统上面，只需要在lighttpd.conf配置文件如下配置，lighttpd就会使用sendfile方式处理静态资源的下载，效率非常高：
但是在某些情况下，我们却无法直接让lighttpd处理文件的下载，比方说JavaEye网站需要统计帖子附件的下载次数，博客相册的点击次数，比方说需要对下载的文件进行权限的控制，特别是对于一些多用户系统，你不能让用户上传的私密文件被其他用户随便下载到，例如JavaEye圈子的共享文件不能够对圈子外的用户开放下载。因此，文件下载目录千万不能放到public目录下，不能让用户直接通过浏览器的URL地址访问到。在这种情况下，文件下载必须由服务器端应用程序来处理。
在RoR应用当中，我们可以在controller中使用send_file方法来控制文件的下载。send_file方法将下载的文件以4KB为单位写到一个输出流去。如果我们使用mongrel应用服务器的话，mongrel会在内存当中创建一个StringIO对象，把整个下载文件完整的读入内存，然后再向客户端或者前端的Web服务器写出。如果我们使用fcgi来运行RoR的话，fcgi会直接把输出流的内容向前端的Web服务器写出。
毫无疑问，我们可以看到这种下载处理方式有很大的性能缺陷：
1、当使用mongrel的时候，如果下载文件很大，会导致mongrel内存暴涨！
mongrel创建一个StringIO对象缓存整个输出内容，我们假设用户下载的是一个100MB的文件，该用户又很喜欢用多线程下载工具，他开了10个线程并发下载，那么mongrel的内存占用会暴涨1GB以上。而且最可怕的是，即使当用户下载结束以后，mongrel的内存都不会迅速回落，而是一直保持如此高的内存占用。这个缺陷非常容易被别有用心的黑客利用，攻击网站。这也是JavaEye网站为什么始终不用mongrel的原因之一。
2、当使用fcgi的时候，如果前端Web服务器没有足够大buffer，会导致fcgi进程被挂住
fcgi自己不开output buffer，而是实时写出输出内容，如果前端Web服务器用的是lighttpd，那么你很幸运，lighttpd会照单全收，一个字节都不拉下；如果前端Web服务器用的是nginx/apache，那么你很不幸，nginx/apache默认只开8K的buffer，收不下的那就对不起了，您慢点嘞，fcgi进程就被挂住了，只要客户端浏览器下载不结束，fcgi进程就被一直占用。
3、即使使用lighttpd+fcgi，也会对服务器造成不小的性能开销
lighttpd+fcgi是最理想的Rails部署环境，JavaEye网站使用的就是lighttpd+fcgi。当ruby程序执行send_file开始下载的时候，fcgi会以4KB为单位读入文件内容，然后立刻写出到lighttpd去，而lighttpd照单全收。因此当下载文件被完整的通过fcgi被flush到lighttpd的内存里面去以后，即使你杀掉fcgi进程，都丝毫不会影响文件下载。
也许你会问，lighttpd都吃下来文件内容，内存会不会暴涨？会的，我们假设同样的用户场景，某用户启动10个线程下载100MB的文件，fcgi进程内存不会发生变化，但是lighttpd会暴涨1GB。但所幸的是lighttpd的内存管理的不错，一旦用户取消下载，或者下载完毕，lighttpd立刻释放掉1GB的内存。
但是无论怎么说，ruby还是需要完整的读取下载文件，而lighttpd也需要开辟足够大的内存，处理整个文件的下载过程，对服务器开销还是很大的。我们的问题是，能不能让带权限控制的文件下载像lighttpd下载静态资源文件那样快，开销那样小呢？答案就是X-sendfile！
使用X-sendfile方式，服务器端应用程序不需要读取下载文件了，只需要设置response的header信息就足够了，此外还要附加一个信息“X-LIGHTTPD-send-file”信息给lighttpd，告诉lighttpd，文件下载我就不管了，你自己看着办吧：
X-LIGHTTPD-send-file告诉lighttpd，去硬盘的哪个路径找要下载的文件，最后一行啥都不输出了，下载不用ruby来管了。
而lighttpd收到X-LIGHTTPD-send-file信息以后，就会找到硬盘该文件，以静态资源文件的下载方式处理，丝毫不消耗lighttpd的内存。还是以某用户启动10个线程下载100MB文件为例，10个fcgi进程发送了response信息就处理完毕了，而lighttpd知道下载的是硬盘的静态文件，会以sendfile方式下载，文件内容就会被操作系统内核直接送到网卡的buffer里面，既不消耗ruby进程，也不消耗lighttpd，皆大欢喜。
在lighttpd-1.4.18版本里面，fastcgi方式已经内置X-sendfile支持，仅仅需要你在配置文件打开就可以了：
这样我们就可以在RoR应用中使用X-sendfile飞速的下载文件了。但是慢着，免费的午餐有这么容易享用吗？ 如果你已经按照我的介绍进行了相关的配置，那么你会失望的发现，下载文件会出问题，无论多大的文件，下载到本地都只有1KB，怎么回事？ 这是Rails一个可耻的bug！经过我们努力的摸索和钻研，终于搞清楚的原因以及fix bug的方法，目前好像在互联网上面还搜索不到任何解决相关问题的办法，那么我们提出的解决方案看来是首开先河了。
Rails的render机制在输出页面之前，会根据输出内容的长度来设置response信息的Content-Length，如果输出的内容是页面，这一步是必须的操作。但如果是X-sendfile的话，我们在程序当中 render :nothing => true了，于是Rails就会错误的设置Content-Length为1KB (为什么不是0KB呢？这是因为render :nothing实际上输出一个空白或者回车之类的字符，又是一个可耻的问题！)， 覆盖掉我们在程序当中设置的Content-Length。而lighttpd在处理X-sendfile的时候也明显大脑进水，它不会根据硬盘文件的实际长度来确定Content-Length，而是顽固的相信Rails告诉他的Content-Length就是1KB，最后我们会悲哀的发现下载文件只有1KB，而且是下载文件的第一个字符。
为什么说这是Rails一个可耻的bug呢？因为这个bug已经被多次报告到Rails的Trac上面，但是直至最新的Rails2.0的SVN，仍然拒绝被修复。所以这个世界没有无缘无故的爱，也没有无缘无故的恨，Mongrel作者Zed Shaw造反Rails社区是有原因滴。没有办法啦，我们只好自己动手修复：
在我们的Rails项目的lib目录下面创建子目录action_controller，然后在这个子目录下面创建文件cgi_response.rb，文件内容如下：
打开了ActionController::CgiResponse类，覆盖掉set_content_length!方法，当reponse的信息当中包含X-LIGHTTPD-send-file的时候，避免Rails覆盖我们的Content-Length设置。这样X-sendfile功能就可以正常使用了。然后在app/controllers/application.rb里面引入这个文件：
作为最流行的轻量级Web服务器的翘楚，lighttpd提供了良好的sendfile支持，JavaEye网站服务器使用的就是lighttpd。在Linux操作系统上面，只需要在lighttpd.conf配置文件如下配置，lighttpd就会使用sendfile方式处理静态资源的下载，效率非常高：
引用
server.network-backend = "linux-sendfile"
但是在某些情况下，我们却无法直接让lighttpd处理文件的下载，比方说JavaEye网站需要统计帖子附件的下载次数，博客相册的点击次数，比方说需要对下载的文件进行权限的控制，特别是对于一些多用户系统，你不能让用户上传的私密文件被其他用户随便下载到，例如JavaEye圈子的共享文件不能够对圈子外的用户开放下载。因此，文件下载目录千万不能放到public目录下，不能让用户直接通过浏览器的URL地址访问到。在这种情况下，文件下载必须由服务器端应用程序来处理。
在RoR应用当中，我们可以在controller中使用send_file方法来控制文件的下载。send_file方法将下载的文件以4KB为单位写到一个输出流去。如果我们使用mongrel应用服务器的话，mongrel会在内存当中创建一个StringIO对象，把整个下载文件完整的读入内存，然后再向客户端或者前端的Web服务器写出。如果我们使用fcgi来运行RoR的话，fcgi会直接把输出流的内容向前端的Web服务器写出。
毫无疑问，我们可以看到这种下载处理方式有很大的性能缺陷：
1、当使用mongrel的时候，如果下载文件很大，会导致mongrel内存暴涨！
mongrel创建一个StringIO对象缓存整个输出内容，我们假设用户下载的是一个100MB的文件，该用户又很喜欢用多线程下载工具，他开了10个线程并发下载，那么mongrel的内存占用会暴涨1GB以上。而且最可怕的是，即使当用户下载结束以后，mongrel的内存都不会迅速回落，而是一直保持如此高的内存占用。这个缺陷非常容易被别有用心的黑客利用，攻击网站。这也是JavaEye网站为什么始终不用mongrel的原因之一。
2、当使用fcgi的时候，如果前端Web服务器没有足够大buffer，会导致fcgi进程被挂住
fcgi自己不开output buffer，而是实时写出输出内容，如果前端Web服务器用的是lighttpd，那么你很幸运，lighttpd会照单全收，一个字节都不拉下；如果前端Web服务器用的是nginx/apache，那么你很不幸，nginx/apache默认只开8K的buffer，收不下的那就对不起了，您慢点嘞，fcgi进程就被挂住了，只要客户端浏览器下载不结束，fcgi进程就被一直占用。
3、即使使用lighttpd+fcgi，也会对服务器造成不小的性能开销
lighttpd+fcgi是最理想的Rails部署环境，JavaEye网站使用的就是lighttpd+fcgi。当ruby程序执行send_file开始下载的时候，fcgi会以4KB为单位读入文件内容，然后立刻写出到lighttpd去，而lighttpd照单全收。因此当下载文件被完整的通过fcgi被flush到lighttpd的内存里面去以后，即使你杀掉fcgi进程，都丝毫不会影响文件下载。
也许你会问，lighttpd都吃下来文件内容，内存会不会暴涨？会的，我们假设同样的用户场景，某用户启动10个线程下载100MB的文件，fcgi进程内存不会发生变化，但是lighttpd会暴涨1GB。但所幸的是lighttpd的内存管理的不错，一旦用户取消下载，或者下载完毕，lighttpd立刻释放掉1GB的内存。
但是无论怎么说，ruby还是需要完整的读取下载文件，而lighttpd也需要开辟足够大的内存，处理整个文件的下载过程，对服务器开销还是很大的。我们的问题是，能不能让带权限控制的文件下载像lighttpd下载静态资源文件那样快，开销那样小呢？答案就是X-sendfile！
使用X-sendfile方式，服务器端应用程序不需要读取下载文件了，只需要设置response的header信息就足够了，此外还要附加一个信息“X-LIGHTTPD-send-file”信息给lighttpd，告诉lighttpd，文件下载我就不管了，你自己看着办吧：
- response.headers['Content-Type'] = @attachment.content_type
- response.headers['Content-Disposition'] = "attachment; filename=\"#{URI.encode(@attachment.filename)}\""
- response.headers['Content-Length'] = @attachment.size
- response.headers["X-LIGHTTPD-send-file"] = @attachment.public_filename
- render :nothing => true
response.headers['Content-Type'] = @attachment.content_type
response.headers['Content-Disposition'] = "attachment; filename=\"#{URI.encode(@attachment.filename)}\""
response.headers['Content-Length'] = @attachment.size
response.headers["X-LIGHTTPD-send-file"] = @attachment.public_filename
render :nothing => true
X-LIGHTTPD-send-file告诉lighttpd，去硬盘的哪个路径找要下载的文件，最后一行啥都不输出了，下载不用ruby来管了。
而lighttpd收到X-LIGHTTPD-send-file信息以后，就会找到硬盘该文件，以静态资源文件的下载方式处理，丝毫不消耗lighttpd的内存。还是以某用户启动10个线程下载100MB文件为例，10个fcgi进程发送了response信息就处理完毕了，而lighttpd知道下载的是硬盘的静态文件，会以sendfile方式下载，文件内容就会被操作系统内核直接送到网卡的buffer里面，既不消耗ruby进程，也不消耗lighttpd，皆大欢喜。
在lighttpd-1.4.18版本里面，fastcgi方式已经内置X-sendfile支持，仅仅需要你在配置文件打开就可以了：
引用
"allow-x-send-file"="enable"
这样我们就可以在RoR应用中使用X-sendfile飞速的下载文件了。但是慢着，免费的午餐有这么容易享用吗？ 如果你已经按照我的介绍进行了相关的配置，那么你会失望的发现，下载文件会出问题，无论多大的文件，下载到本地都只有1KB，怎么回事？ 这是Rails一个可耻的bug！经过我们努力的摸索和钻研，终于搞清楚的原因以及fix bug的方法，目前好像在互联网上面还搜索不到任何解决相关问题的办法，那么我们提出的解决方案看来是首开先河了。
Rails的render机制在输出页面之前，会根据输出内容的长度来设置response信息的Content-Length，如果输出的内容是页面，这一步是必须的操作。但如果是X-sendfile的话，我们在程序当中 render :nothing => true了，于是Rails就会错误的设置Content-Length为1KB (为什么不是0KB呢？这是因为render :nothing实际上输出一个空白或者回车之类的字符，又是一个可耻的问题！)， 覆盖掉我们在程序当中设置的Content-Length。而lighttpd在处理X-sendfile的时候也明显大脑进水，它不会根据硬盘文件的实际长度来确定Content-Length，而是顽固的相信Rails告诉他的Content-Length就是1KB，最后我们会悲哀的发现下载文件只有1KB，而且是下载文件的第一个字符。
为什么说这是Rails一个可耻的bug呢？因为这个bug已经被多次报告到Rails的Trac上面，但是直至最新的Rails2.0的SVN，仍然拒绝被修复。所以这个世界没有无缘无故的爱，也没有无缘无故的恨，Mongrel作者Zed Shaw造反Rails社区是有原因滴。没有办法啦，我们只好自己动手修复：
在我们的Rails项目的lib目录下面创建子目录action_controller，然后在这个子目录下面创建文件cgi_response.rb，文件内容如下：
- module ActionController # fix rails X-sendfile bug!
- class CgiResponse
- def set_content_length!
- @headers["Content-Length"] = @body.size unless @body.respond_to?(:call) || @headers["X-LIGHTTPD-send-file"]
- end
- end
- end
module ActionController # fix rails X-sendfile bug!
class CgiResponse
def set_content_length!
@headers["Content-Length"] = @body.size unless @body.respond_to?(:call) || @headers["X-LIGHTTPD-send-file"]
end
end
end
打开了ActionController::CgiResponse类，覆盖掉set_content_length!方法，当reponse的信息当中包含X-LIGHTTPD-send-file的时候，避免Rails覆盖我们的Content-Length设置。这样X-sendfile功能就可以正常使用了。然后在app/controllers/application.rb里面引入这个文件：
- require 'action_controller/cgi_response'
require 'action_controller/cgi_response'
JavaEye网站在使用了X-sendfile功能之后，lighttpd的内存占用有明显的下降。未使用X-sendfile之前，lighttpd有时候内存占用会到200MB以上(有用户多线程下载附件)，在使用X-sendfile之后，lighttpd的内存占用还从未突破20MB。
最后要提醒大家几个问题：
1、lighttpd-1.4.18不认X-sendfile这个header，只认X-LIGHTTPD-send-file
按照lighttpd网站自己的文档，以及各种各样流行的X-sendfile文档，设置的header都是X-sendfile，但是经过我们n次失败的摸索，才发现原来必须使用X-LIGHTTPD-send-file，这一点请不要被文档迷惑，目前好像也只有我们提出这个解决办法，互联网上面尚未看到其他人提出过，看来我们又首开先河了。用RoR就是这点好，你动不动就得自己先去当尝螃蟹的那个人。
2、lighttpd-1.5.0版本的X-sendfile设置有所改变
lighttpd-1.5.0版本还未发布正式版本，据说1.5.0已经认识X-sendfile这个header了，这个大家有兴趣自己测试吧。
3、Rails2.0版本仍然存在这个X-sendfile的bug
我们的fix方法目前是在Rails1.2.6上面编写的，针对Rails2.0版本应该也是有效的，但是我们还没有测试过，有兴趣的同学自己测试一下吧。
补充几句：
1、lighttpd-1.4.18仅支持fastcgi情况下的X-sendfile，而1.5.0版本则支持各种情况包括fastcgi, scgi, http proxy, ajp等协议下的X-sendfile
2、apache不支持X-sendfile，可以通过第三方mod添加支持，但据说不太好用
3、nginx有类似lighttpd的X-sendfile，叫做X-Accel-Redirect，但是使用的限制比较大，必须实现在nginx上面配置到某个目录下的文件才具备这样的功能，而不像lighttpd，任意目录文件不需要配置都可以支持，因而很受人批评。
当然，我还是推荐大家使用lighttpd+fcgi，这是性能最佳Rails方案，我会另外写文章剖析Rails部署方案的优劣。