一个RoR的站点性能优化的故事(4) | ityum.net

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

原文链接: http:///articles/2006/04/03/the-adventures-of-scaling-stage-4

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

第四篇 速度快和稳定

在2005年的11月至2006年的3月，许多优化的工作都在这期间完成。这里面不少工 作都不得不变成了配置的一部分（比如第三篇提到的请求分发的监控脚本）。最终经过了几周的运行，这个网站被证明是稳定且速度快的。另外，我们也已经能完成 一点从用户和社区运营人员那里的需求。

完成过程中的闪光点

二月份，一些小的调整让系统性能变得更好。

第一，当用户编写个人消息和在论坛发帖时，我们利用AJAX来对其内容进行预览。虽然这不是性能的杀手，但把这因素剔除来减轻压力是有意思的。呃，在AOL浏览器中prototype会崩溃。

另外，将作为lighttpd守护进程对待。这样崩溃的现象在1.4.8及以后的版本就很少出现了，但仍然需要监控进程的情况。要知道如果lighttpd down了整个网站就down了。所以得看好它。（译者评：这里可能会出现单点失败的情况，clear & dirty）

将lighttpd作为daemontools 来跑是非常简单的。简单配置以后（具体配置这些写得很清楚 http://www./daemontools.html）你在ROR的service树下面用一行脚本来用damontools 配置lighttpd服务。你会知道并且爱上Rails最初的script/server。

#!/bin/sh

/usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf

这样就启动好就运行了。你可以通过lighttpd的配置来简单的设置一下，发送 lighttpd的进程ID或这信号SIGINT到你后台的监控中。然后需要注意的是如果你的网站流量非常大就需要把那些不能再完成了服务请求通过 SIGKILL杀死。新发布的lighttpd1.4.11分发请求时候的僵死越来越少了，似乎这种情况完全没了。但我们将继续通过脚本监控它。

到此是这一些列文章的结束了。现在服务器每天支撑1.2M的PV（100GB的流量）。

总结以及以后的计划

以下是这四个月被证明是非常有用的优化手段：

系统优化：

>使用Linux 2.6代替2.4

>使用自己编译的Ruby 1.8.4

>使用Mysql官方的二进制版本

>使用lighttpd 1.4.11代替以前的

>使用memcache-client代替Ruby-MemCache

>使用了更少数量的dispatchers

>并且监控你的dispathchers

代码优化：

>避免使用ROR的组建 components

>用memcached储存费时的计算

>用memcached来存储session

>如果你的站点很受欢迎就不要使用live-previews

>使用异常通知exception notification来捕捉可能的异常

另外不要完全相信这些总结。优化是一个发展中的东西。

你需要一直对网站进行监控，包括你的服务器和所有相关的软件。

强烈建议不仅仅只监控服务是否起来了，还好监控服务器的压力，响应时间等等。用Nagios和Cacti结合起来做这些工作被我们证明是很有用的。

提 醒注意的是，需要读读所有你使用的软件包的改变日志，看看新的版本中解决了什么已经存在的问题，可能产生哪些新问题。不需要强制升级所有的更新，但对你正 困扰的问题在新版本中别解决了，你就一定要升了。你可以在测试环境中进行测试，减少当机时间，避免升级带来的潜在问题。

请留心你网站代码的变化。一般来说，应该多想想我要做什么。一个像Rails这样聪明的框架会让你有机会去思考，而不是每天写些重复性的代码。要聪明的使用时间。

一条SQL语句或单个循环可能在你开发用的笔记本上跑的很快，但是在产品环境中同时并发执行成百上千次或产品中数据量比较大都有可能导致网站变慢。

性能调优准则
总的来说，不太容易把网站的性能调节好。
一种方式是让网站处于非生产状态，也就是测试状态，自己产生一些流量来测试，这样的流量不同于真实的用户产生的流量。这样模拟的网站数据集也不同于线上的正式产品。这种情况下所有的调优结果都要根据线上真实网站的情况进行一下转换。
另 一种方式是对线上实际网站逐步地进行性能调优。这样有许多好处，你有真实的用户在使用你的功能，使用你的系统，正如数据一样所有这些都是真实的，比测试环 境有价值的多。但这种方式主要问题是，如果你的网站访问量特别大，系统的日志production.log将会大量快速的被写到硬盘上，这样你就很难找到 问题。如果做日志的分离，将实际的日志相互关联起来也不太容易。那么将日志重定向成系统日志Syslog（通过 SysLogger，在Rails Analyzer Tools包里面），它能将每个日志同一个线程ID关系，这样就非常方便了。

写大文件的日志意味这你整个系统的IO补偿糟糕，如果你在产品环境中不要写太多太详细的日志，系统将会比你测试的结果跑得好得多。
哦，当网站调优时，拆分用户将会有比较好的效果，但更重要是的要不断听声网站的使用体验。

使用过的工具：
将前面提到的Rails Analyzer Tools 包放在手边，这些工具在类UNIX系统里面非常管用。你还需要会几个命令，cat,tail,grep,awk,ps,netstat。另外，安装一下 ngrep和tcpdump来debug网络流量，还可以用mytop来查看Mysql线程列表。

把这些都准备好需要一些时间、耐心和知识，也偶尔需要Google搜索一下。

将来还要处理的事情

随着memcache-client库的发布，Robot Coop公司又发布了另一个小的库，名字叫做cached_model ，这是基于memcached用于减轻数据库重复查询，原理就是在查询之前通过子类Active::Base来检查memcached中的内容。

我在1.0版本它出现的时候，看过一下，觉得还是很有发展的。那个时候它不能很好的集成，经常胡乱抛错。由于当时我们忙于调试其它的问题，就没有仔 细地去 解决这些问题。在此期间，cached_model版本升级到了1.1.0，也修复了多个bug。这个东西也将包括与我们将来优化的路线图当中了。

在第三篇的时候我们碰到了一个“分发请求僵住”的问题，我们将回来再看看FastCGI ，更通常的办法是用lighttpd也支持的SCGI。

有Zed Shaw发布了新的软件Mongrel 已经开始出售了。它作为“比WEBrick”更好的应用服务器，将纯HTTP放到FastCGI中，非常值得多看看。在读者评论中

有人说早期Dan Kubb提到用Canditional GET ,它的潜在好处是在缓存页面不变时它可以用浏览器来缓存页面。我只是简单地看了一下它的标题，Rails插件看上去还不错，很容易集成进来。

有个比较大的变化，尽管我曾经提倡使用Mysql的全文检索，但现在我正在基于Rails的一个搜索插件工作，它很容易无缝滴集成到Hyper Estraier 搜索引擎中。如果它跑的很好（性能好和数据保护），我们将丢掉全文检索，弄一个纯InnoDB的数据库配置，并且向锁表和非事务的测试说再见了，同时这样 也不能使用ROR的schema.rb了。

说道这里，我们升级到了了最近的Rails1.1。尽管这次升级对于性能并没有太大的必要，但是它有另外受欢迎的地方，它使得我们代码变得漂亮简介了。

谢谢看过这一系列文章的人们。我真诚的希望我对我们案例的详细描述能够避免再去做我们已经做好了的一些研究和调试工作。如果你需要任何帮助，只要记下我的email,通过联系limited overload我可以作为咨询顾问来帮助你。

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

原文链接: http:///articles/2006/04/03/the-adventures-of-scaling-stage-4

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

第四篇 速度快和稳定

在2005年的11月至2006年的3月，许多优化的工作都在这期间完成。这里面不少工 作都不得不变成了配置的一部分（比如第三篇提到的请求分发的监控脚本）。最终经过了几周的运行，这个网站被证明是稳定且速度快的。另外，我们也已经能完成 一点从用户和社区运营人员那里的需求。

完成过程中的闪光点

二月份，一些小的调整让系统性能变得更好。

第一，当用户编写个人消息和在论坛发帖时，我们利用AJAX来对其内容进行预览。虽然这不是性能的杀手，但把这因素剔除来减轻压力是有意思的。呃，在AOL浏览器中prototype会崩溃。

另外，将作为lighttpd守护进程对待。这样崩溃的现象在1.4.8及以后的版本就很少出现了，但仍然需要监控进程的情况。要知道如果lighttpd down了整个网站就down了。所以得看好它。（译者评：这里可能会出现单点失败的情况，clear & dirty）

将lighttpd作为daemontools 来跑是非常简单的。简单配置以后（具体配置这些写得很清楚 http://www./daemontools.html）你在ROR的service树下面用一行脚本来用damontools 配置lighttpd服务。你会知道并且爱上Rails最初的script/server。

#!/bin/sh

/usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf

这样就启动好就运行了。你可以通过lighttpd的配置来简单的设置一下，发送 lighttpd的进程ID或这信号SIGINT到你后台的监控中。然后需要注意的是如果你的网站流量非常大就需要把那些不能再完成了服务请求通过 SIGKILL杀死。新发布的lighttpd1.4.11分发请求时候的僵死越来越少了，似乎这种情况完全没了。但我们将继续通过脚本监控它。

到此是这一些列文章的结束了。现在服务器每天支撑1.2M的PV（100GB的流量）。

总结以及以后的计划

以下是这四个月被证明是非常有用的优化手段：

系统优化：

>使用Linux 2.6代替2.4

>使用自己编译的Ruby 1.8.4

>使用Mysql官方的二进制版本

>使用lighttpd 1.4.11代替以前的

>使用memcache-client代替Ruby-MemCache

>使用了更少数量的dispatchers

>并且监控你的dispathchers

代码优化：

>避免使用ROR的组建 components

>用memcached储存费时的计算

>用memcached来存储session

>如果你的站点很受欢迎就不要使用live-previews

>使用异常通知exception notification来捕捉可能的异常

另外不要完全相信这些总结。优化是一个发展中的东西。

你需要一直对网站进行监控，包括你的服务器和所有相关的软件。

强烈建议不仅仅只监控服务是否起来了，还好监控服务器的压力，响应时间等等。用Nagios和Cacti结合起来做这些工作被我们证明是很有用的。

提 醒注意的是，需要读读所有你使用的软件包的改变日志，看看新的版本中解决了什么已经存在的问题，可能产生哪些新问题。不需要强制升级所有的更新，但对你正 困扰的问题在新版本中别解决了，你就一定要升了。你可以在测试环境中进行测试，减少当机时间，避免升级带来的潜在问题。

请留心你网站代码的变化。一般来说，应该多想想我要做什么。一个像Rails这样聪明的框架会让你有机会去思考，而不是每天写些重复性的代码。要聪明的使用时间。

一条SQL语句或单个循环可能在你开发用的笔记本上跑的很快，但是在产品环境中同时并发执行成百上千次或产品中数据量比较大都有可能导致网站变慢。

性能调优准则
总的来说，不太容易把网站的性能调节好。
一种方式是让网站处于非生产状态，也就是测试状态，自己产生一些流量来测试，这样的流量不同于真实的用户产生的流量。这样模拟的网站数据集也不同于线上的正式产品。这种情况下所有的调优结果都要根据线上真实网站的情况进行一下转换。
另 一种方式是对线上实际网站逐步地进行性能调优。这样有许多好处，你有真实的用户在使用你的功能，使用你的系统，正如数据一样所有这些都是真实的，比测试环 境有价值的多。但这种方式主要问题是，如果你的网站访问量特别大，系统的日志production.log将会大量快速的被写到硬盘上，这样你就很难找到 问题。如果做日志的分离，将实际的日志相互关联起来也不太容易。那么将日志重定向成系统日志Syslog（通过 SysLogger，在Rails Analyzer Tools包里面），它能将每个日志同一个线程ID关系，这样就非常方便了。

写大文件的日志意味这你整个系统的IO补偿糟糕，如果你在产品环境中不要写太多太详细的日志，系统将会比你测试的结果跑得好得多。
哦，当网站调优时，拆分用户将会有比较好的效果，但更重要是的要不断听声网站的使用体验。

使用过的工具：
将前面提到的Rails Analyzer Tools 包放在手边，这些工具在类UNIX系统里面非常管用。你还需要会几个命令，cat,tail,grep,awk,ps,netstat。另外，安装一下 ngrep和tcpdump来debug网络流量，还可以用mytop来查看Mysql线程列表。

把这些都准备好需要一些时间、耐心和知识，也偶尔需要Google搜索一下。

将来还要处理的事情

随着memcache-client库的发布，Robot Coop公司又发布了另一个小的库，名字叫做cached_model ，这是基于memcached用于减轻数据库重复查询，原理就是在查询之前通过子类Active::Base来检查memcached中的内容。

我在1.0版本它出现的时候，看过一下，觉得还是很有发展的。那个时候它不能很好的集成，经常胡乱抛错。由于当时我们忙于调试其它的问题，就没有仔 细地去 解决这些问题。在此期间，cached_model版本升级到了1.1.0，也修复了多个bug。这个东西也将包括与我们将来优化的路线图当中了。

在第三篇的时候我们碰到了一个“分发请求僵住”的问题，我们将回来再看看FastCGI ，更通常的办法是用lighttpd也支持的SCGI。

有Zed Shaw发布了新的软件Mongrel 已经开始出售了。它作为“比WEBrick”更好的应用服务器，将纯HTTP放到FastCGI中，非常值得多看看。在读者评论中

有人说早期Dan Kubb提到用Canditional GET ,它的潜在好处是在缓存页面不变时它可以用浏览器来缓存页面。我只是简单地看了一下它的标题，Rails插件看上去还不错，很容易集成进来。

有个比较大的变化，尽管我曾经提倡使用Mysql的全文检索，但现在我正在基于Rails的一个搜索插件工作，它很容易无缝滴集成到Hyper Estraier 搜索引擎中。如果它跑的很好（性能好和数据保护），我们将丢掉全文检索，弄一个纯InnoDB的数据库配置，并且向锁表和非事务的测试说再见了，同时这样 也不能使用ROR的schema.rb了。

说道这里，我们升级到了了最近的Rails1.1。尽管这次升级对于性能并没有太大的必要，但是它有另外受欢迎的地方，它使得我们代码变得漂亮简介了。

谢谢看过这一系列文章的人们。我真诚的希望我对我们案例的详细描述能够避免再去做我们已经做好了的一些研究和调试工作。如果你需要任何帮助，只要记下我的email,通过联系limited overload我可以作为咨询顾问来帮助你。