2024年6月11日发(作者：)

Web架构布置

Web架构布置2010-04-07 11：55这篇文章虽然是将ror的,但是对于整个web开

发还是非常有意义的，我也总结了下这篇文章，发现web程序还是很有共性的.1：

负载均衡器大型网站肯定不是单台服务器的,为了做负载均衡,一般用F5,DNS轮询.

我们公司所有的静态页面则采用NGINX做代理,后端挂SQUID服务器.NGINX的代理

模块能够根据url地址HASH到某组服务器上,NGINX做负载均衡,SQUID组则考虑容

灾问题.2：WEB缓存服务器原来我们公司使用文件cache,在新版本中使用squid作

为页面缓存,squid组根据不同地区做IDC分布,形成了分布式的系统.从实际效果

上看,文件cache更容易控制,程序使用比较灵活.考虑到不同的应用ncache可能逐

步替代squid.3：后端服务器后端服务器就是应用服务器,主要通过F5挂在squid

服务集群后面,处理的都是动态请求,每台机器每天50万的请求,cpu负载也不高,

并发请求没有超过100,使用的是apache1.3,lamp的组合.先写到这儿干活

了….JavaEye网站的RoR性能优化经验谈JavaEye网站从2006年9月11日上线

基于RoR的2.0版本开始，到现在已经运行了将近一年半了。在这一年半的时间

里，JavaEye网站的每日PV从最开始的5万，缓慢增长到了现在的60万。随着网

站负载的不断增加，我们也在不断尝试和调整网站的性能，积累了不少第一手RoR

应用性能优化的实战经验。虽然我们并不是RoR性能优化的权威专家，我们所积累

的经验也许并不是最优实践，但是作为国内最早涉足RoR商业运营的互联网网站之

一，我们非常乐意分享和交流我们的实战经验，以帮助后来者节省必要的摸索时

间。RoR惊人的开发速度恐怕是每个互联网创业者都梦寐以求的，但是随着网站流

量的不断增大，可能大多数采用RoR的网站或迟或早会遇到RoR的性能瓶颈，我的

一个朋友capitian说过一句很有意思的话："RoR应用做到后来，总有自己修改底

层的冲动"。就我所了解和掌握的情况来看，很多RoR网站都过早的遇到了性能瓶

颈，一个很普遍的现象就是：RoR应用的CPU负载要远远高于数据库的负载。这是

一个有点违背常理的现象，因为我们知道，硬盘IO速度要比内存慢得多，所以一

般Web应用的性能瓶颈往往会出现在数据库IO上，因此优化数据库，进行对象缓

存是非常有效的性能优化手段。但是一旦应用服务器负载比数据库还高的话，单纯

的对象缓存就无用武之地了。下面我们从几个方面分别谈一谈如何进行RoR的性能

优化：应用的部署RoR应用的部署包括操作系统，Web服务器，应用服务器和数据

库四个方面：一、操作系统1、发行版本RoR适合于部署在Unix类操作系统上

面，通常比较多的人使用RHEL/CentOS/Ubuntu，我们比较偏爱SuSE Linux，对于

我们服务器使用的AMD Opteron x86_64的CPU来说，SLES要比RHEL有更多的优

化。另外应该尽量使用64位版本操作系统，以充分发挥x86_64 CPU的性能，并且

x86_64的Linux很多Kernel参数也大很多，代价就是需要更多的物理内存。2、

文件系统Linux最常用的文件系统是ext3，但我们使用的是Reiserfs文件系统。

Reiserfs在读写大量小文件的目录性能非常高，即使处理目录下面直接存放10万

个文件，性能仍然不会下降。我们知道默认情况Rails会对每个浏览器会话在硬盘

生成session文件，一个繁忙的网站，临时文件目录下面有上万乃至几万个

session文件是很常见的现象。对于这种目录下面几万个小文件的存取，reiserfs

要比ext3性能高一个数量级。如果希望对session文件有更好的存取性能，可以

把临时目录链接到Linux的内存文件系统/dev/shm目录下面，这样实际上session

文件的存取都是直接内存操作了，这种方式唯一的问题在于不能支持群集部署。如

果你已经升级到了Rails2.0，可以采取把session保存到Cookie里面的方式，既

可以避免服务器处理session的开销，而且还支持群集部署，是大规模网站部署的

首选方式。3、内核的网络参数调整对于流量很大的网站来说，默认的Linux内核

网络参数偏小，因此如果你的网站流量非常大，或者上传下载大文件比较多，可以

针对性的调整内核网络参数，扩大内核的TCP接收数据和发送数据的Buffer缓冲

区大小，比方说：引用_default=262144

_default=262144 _max=262144

_max=262144 _rmem=4096 65536 524288

_wmem=4096 65536 524288参数具体调整，可以Google相关的Linux

内核参数的文档，这里不展开详谈。二、Web服务器Web服务器首选Lighttpd，因

为Lighttpd在和后端的应用服务器通讯方式上做了足够的优化：当POST大数据量

的时候，Lighttpd在完整的接收客户端浏览器的数据之后，才会一次性发送给应

用服务器；同样的，Lighttpd也是一次性把应用服务器处理的页面数据全部接

收，不设置Buffer Size的限制。因此Lighttpd能够尽最大可能的减轻应用服务

器的负担，减少应用服务器用于处理数据传输的延迟，更加有效的利用应用服务器

资源。这方面的详细的论述请看：RoR部署方案深度剖析。关于Lighttpd的安装

可以参考在Linux平台上安装和配置Ruby on Rails详解，这里仅谈Lighttpd的

性能优化的几个要点：1、网络IO调度方式Linux Kernel 2.6支持sysepoll方式

调度网络IO，能够处理极高的并发连接请求，Lighttpd可以通过配置文件打开

sysepoll支持：引用-handler="linux-sysepoll"2、网络IO传输方

式Linux Kernel 2.6支持sendfile方式传输数据，Lighttpd可以通过配置文件

打开sendfile支持：引用k-backend="linux-sendfile"此外

Lighttpd还支持应用服务器参与的文件下载控制X-sendfile，详细的论述请看：

RoR网站如何利用lighttpd的X-sendfile功能提升文件下载性能3、文件状态缓

存Lighttpd通过stat()调用获得文件被修改的信息，来决定当请求同一个静态文

件资源的时候，是否需要再次读取硬盘文件。但是每次stat()调用也有一定的开

销，Lighttpd支持通过Fam Server来减少stat调用。即每次当文件被修改之

后，Kernel会发送一个消息通知Fam Server，而Lighttpd会通过进程间通讯连接

Fam Server，可以知道文件是否被修改的信息，不必再每次调用stat()。引用

-cache-engine="fam"4、限定POST Size为了避免黑客恶意的攻击服

务器，伪造超大Post数据包轰炸Web服务器和应用服务器，可以限制Request请

求的大小，例如限制为10MB：引用-request-size=10240 5、文件

Lighttpd是单进程单线程的服务器，调度网络IO性能是极高的，但是在某些极端

情况下，单进程服务器也有风险，即一旦被某操作系统调用挂住，整个服务器就没

有办法响应请求了。比方说服务器其他进程导致的IO WAIT很高，操作系统的

buffer又不够的时候，Lighttpd在大量的写access log就有被挂住的可能性。因

此如果Lighttpd日志对你的参考价值不大，可以考虑关闭掉。像JavaEye网站每

天Lighttpd产生430万条log，对硬盘IO也是一个不小的负担，既然已经开着