网站性能优化实例.doc

一个RoR的站点性能优化的故事 Posted on September 28th ?译者： 终于翻译完了这四篇文章，这次翻译的初衷是为网站架构华人社区弄一篇有一定意义的技术文章，用来庆祝其网站开张。这篇文章的意义不在于阐述了多少高深的技 术，而是告诉我们“高手”是如何一步步逼近问题的本质的，国内还没有出现类似的文章，非常值得一看。现在翻译完了，赠与网站架构华人社区，对于转载该文请 联系khan.chan[at]，对于内容本身的问题可联系shiweitao[at]。 The original address of these Articles : The adventures of scaling, Stage 1 The adventures of scaling, Stage 2 The adventures of scaling, Stage 3 The adventures of scaling, Stage 4 一次网站升级的“冒险” 关于这一系列文章 许多大流量的网站都是由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 HDDs RAID-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/每秒的数据通过代理服务器的网卡。（译者评：饿滴神）? 我们使用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都有延迟，与此同时，对于系统做大可