Rails应用性能优化（1）-RailsConf2006

是否觉得你的Rails应用响应速度过于缓慢呢？这是RailsConf2006上的一篇关于Rails应用性能优化的演讲稿，希望能够对你有所帮助。

在优化你的应用之前，我们首先需要明确以下几点：

不先进行性能测试就盲目的优化是非常愚蠢的
如果你的应用是因为设计不合理而导致性能低下，那么我建议你最好花点时间重构你的代码，而不是进行局部的优化，这只会使问题越来越多。
在优化之前，最好先为自己树立一个目标，这样可以防止因为过度优化而浪费时间，达到预期的目标后就该适可而止
没有必要对每一个页面都进行优化，只需要关注那些最经常被访问的页面就可以了，
在开发期间，进行持续的性能测量，这样有助于你在优化时定位性能瓶颈。
在优化完成后，要评估我们优化的质量，我们就需要先确定一组性能参数：

延迟，响应一个请求需要多少时间
吞吐量，每秒最多可以处理多少个请求
系统利用率，在大量请求需要处理的时候，你的系统在满负荷运转吗？
资源开销，在每个请求上所花费的开销
确定了要测量的性能参数，我们需要自动化的基准（benchmark）工具来帮我们进行优化前后的性能对比：

Rails日志文件（debug_level >= Logger::DEBUG)
Rails日志分析工具（需要将日志输出到syslog）
Rails基准脚本（script/benchmarker）
数据库提供的性能分析器
Apache Bench（ab或者ab2）
httperf
railsbench
可在http://rubyforge.org/projects/railsbench/下载
我推荐Railsbench，它可以测量Rails处理一个请求的原始性能，关于Railsbench后面的文章会有介绍。
除了基准测试工具，你也可以选择单纯的性能测试工具：

Ruby profiler
Zen profiler
rubyprof
Rails profiler script
Ruby Performance Validator（商业软件，仅支持windows）
不过事实上，Railsbench已经内置了性能测试工具，所以单独使用这些工具的必要性不大。
工具已经搞定，下面就让我们开始我们的优化之旅吧！

根据我的经验，Rails性能问题一般集中在以下几个方面：

很慢的helper方法
负责的路由
过多的联合（associations）
过多访问数据库
缓慢的session存取
不过，数据库的性能基本可以不用考虑，因为连接数据库的主要开销事实上在于建立ActiveRecord对象。