一个RoR的站点性能优化的故事(1)

应该是去年吧，当时为了庆祝enissue.com开张;朋友Sweater翻译了这系列文章，站点资料丢失了，从Google search中找到重新贴出.

请所有转载者保留署名.

原文链接: http://poocs.net/2006/3/13/the-adventures-of-scaling-stage-1

中文链接: http://ityum.net/2009/08/01/00/02/一个ror的站点性能优化的故事.html

许多大流量的网站都是由Rails支撑的，《WEB开发之道——应用RAILS进行敏捷WEB开发》(第二版) 这本书对于扩展你的应用是非常有帮助的.这个系列的文章是一个实际的例子，例子说明了“如何扩展你的Rail应用？”我会讲述一下我们在提高应用性能时所作的事情。

我们的整个性能调优过程，将分四篇文章来讲述，每一篇都是在我们扩展我们eins.de网站的一个里程碑。文章计划在一周内全部发表出来。

实际情况

我们的任务是重写全部代码，这个在线社区网络eins.de以前是用php写的，原来是一个代码膨胀而且架构的非常糟糕！作为一个在线社区，正如你知道的一样，网站包含如下功能：论坛、评论、个人主页、个人站内消息、编辑内容等等。另外，eins.de在德国的几个大城市都有当地的合作伙伴，他们是各个子版块的重要驱动力。各地的用户是在一个统一的单个数据集中。

原有代码大概由5万行php代码和另外一个闭源的CMS组成（CMS不计入代码行数统计中）组成。这次重写大概只用了5千行Rails代码，就实现原来的大部分功能（原来的一些个功能按计划在这此重写中被剔除了）。

eins.de 每天包含大概120万个动态页面，服务于25个子社区，每个社区是用不同的域名，但所有这些都在一个Rails应用中。然而，还没有到今年的二月，我们对系统配置和代码都做了优化，这样在才能处理如此巨大的流量。

这个网站存在许多动态页面和信息，动态信息是基于用户设置或像在线状态和相互关系状态。这些都是阻碍我们使用Rails本身提供的非常简单的页面缓存或局部缓存。

该应用服务器配置是dual Xeon 3.06GHz, 2GB RAM, SCSI U320 HDDsRAID-1.数据库服务器dual Xeon 3.06GHz, 4GB RAM, SCSI U320 HDDs RAID-1.代理服务器是单台 P4 3.0GHz, 2GB RAM, SCSI U320 HDDs RAID-1.

在不改变硬件条件的前提下，我想准备通过配置优化和修改代码来提高性能，与此同时还要加上一些新功能。

在11月，我们最高每天能够支撑75w的PV（大约有60G的流量），到了来年的3月份，我们很轻松的能够支撑120w的PV（大约有100G的流量），最终性能提升了1.6倍。（译者评：技术真的都变成钱了啊！）

高峰时期通大概20M/每秒的数据通过代理服务器的网卡。（译者评：饿滴神）

well，任何人都不能改变历史，以下是我们以前的系统配置，也就是上面这个图中所示的软件的详细信息。

我们使用Rails中的 ActiveRecodStore来管理session，用 在数据库服务器上的token based single-signon 机制和 memcached来在内存中存储大数据量的计算。

两台数据库服务器通过master-master的方式相互复制，他们的自增ID是相互间隔的。（译者评：比如，一台的ID增长是1、3、5，另一台是2、4、6）.具体实现参看《mysql手册》的auto_increment_increment 和 auto_increment_offset.

haproxy 被用于外部的FastCGI 侦听的负载均衡，以及应用服务器的数据库链接通过它分发到两台数据库服务器上。

以上基本上是一个总体的介绍，性能的优化是非常难的一件事情。基于PHP的老系统处理到90万PV时就会崩溃（这就是说，只要以前一半的应用服务器就行了），而新的架构在巨大的150万PV的时候才会崩溃。这里面不存在突然会变成你所想像的那样好，所有这些变化都在此以前用了无数的日日夜夜coding才达到的。

紧急情况设计
是的，我们曾经正在缴费准备飞到巴哈马群岛，并呆在那。

FastCGI监听数目作为首要的方法从20下降到了10.说实话，原来系统的设置根本没法用.页面每次从开始load都有延迟，与此同时，对于系统做大可支持的负载的失望和一些没有耐心的用户还会重复load让事情变得更糟。用新的设置，这些事情会减少一些，而且快了许多。

过了几天，在新系统上线后，我们又采用了其它几个方法来提高性能，并且修复了一些在测试中没找到的bug.睡觉是多么美好和奢侈的啊。

我们做的几件重要的事情，使得这次升级更加成功：
>强烈指出haproxy，它仍有另外的变量能更调整，直接使用它并不会有明显的效果。所有应用服务器对于Mysql的链接都可以在文件中配置成像连接单个Mysql主机。
FastCGI 连接的分发由lighttpd返回。提示：我们发现要想请求真正均匀的分配到多台应用服务器上，你应该定制fastcgi。服务器的端口和IP的配置应该如下：

"http-1-01" => ( "host" => "10.10.1.10", "port" => 7000 ),"http-2-01" => ( "host" => "10.10.1.11", "port" => 7000 ),"http-3-01" => ( "host" => "10.10.1.12", "port" => 7000 ),"http-4-01" => ( "host" => "10.10.1.13", "port" => 7000 ),"http-1-02" => ( "host" => "10.10.1.10", "port" => 7001 ),"http-2-02" => ( "host" => "10.10.1.11", "port" => 7001 ),"http-3-02" => ( "host" => "10.10.1.12", "port" => 7001 ),"http-4-02" => ( "host" => "10.10.1.13", "port" => 7001 ),

>虽然局部缓存被认为对于用户是不灵活的（数据延迟，不再个性化），并且没有改进，但是还是要使用它。毕竟稍后问题都有反馈。
>停止同时使用两个memcached主机的想法，由于Ruby-MemCache库显然不能很好地处理。实现分布式的方式不是基于一个key，而是随机。让我们最头疼的就是分布式垃圾数据的到期问题。
>重构了工具条的代码，原来这段代码是用Rails中的component，有显示它是性能杀手。一般可以为每一个sidebar的显示设置完整的controller环境。（具体参见 RailsExpress）
>添加gzip的压缩作为after_filter(参见Rails 书中的例子)
>用Mysql slow query log参数来找出速度慢的sql语句，减少表的joins，优化索引。（呵呵，这个显然不是Rails的范围）

这时候已经到了11月，这个时候我们每天可以处理85万PV，似乎没做什么事情，你可以说“太简单了！”

我们新的简化过的设计如下：

第二部分将会着重讲述性能调优，包括mysql调优小技巧，FastGCI 请求分派调优，和更多的系统优化技术。