Rails应用性能优化1
是否觉得你的Rails应用响应速度过于缓慢呢？这是RailsConf2006上的一篇关于Rails应用性能优化的演讲稿，希望能够对你有所帮助。
在优化你的应用之前，我们首先需要明确以下几点：
- 不先进行性能测试就盲目的优化是非常愚蠢的
- 如果你的应用是因为设计不合理而导致性能低下，那么我建议你最好花点时间重构你的代码，而不是进行局部的优化，这只会使问题越来越多。
- 在优化之前，最好先为自己树立一个目标，这样可以防止因为过度优化而浪费时间，达到预期的目标后就该适可而止
- 没有必要对每一个页面都进行优化，只需要关注那些最经常被访问的页面就可以了，
- 在开发期间，进行持续的性能测量，这样有助于你在优化时定位性能瓶颈。
在优化完成后，要评估我们优化的质量，我们就需要先确定一组性能参数：
- 延迟，响应一个请求需要多少时间
- 吞吐量，每秒最多可以处理多少个请求
- 系统利用率，在大量请求需要处理的时候，你的系统在满负荷运转吗？
- 资源开销，在每个请求上所花费的开销
确定了要测量的性能参数，我们需要自动化的基准（benchmark）工具来帮我们进行优化前后的性能对比：
- Rails日志文件（debug_level >= Logger::DEBUG)
- Rails日志分析工具（需要将日志输出到syslog）
- Rails基准脚本（script/benchmarker）
- 数据库提供的性能分析器
- Apache Bench（ab或者ab2）
- httperf
- railsbench
我推荐Railsbench，它可以测量Rails处理一个请求的原始性能，关于Railsbench后面的文章会有介绍。
除了基准测试工具，你也可以选择单纯的性能测试工具：
- Ruby profiler
- Zen profiler
- rubyprof
- Rails profiler script
- Ruby Performance Validator（商业软件，仅支持windows）
不过事实上，Railsbench已经内置了性能测试工具，所以单独使用这些工具的必要性不大。
工具已经搞定，下面就让我们开始我们的优化之旅吧！
根据我的经验，Rails性能问题一般集中在以下几个方面：
- 很慢的helper方法
- 负责的路由
- 过多的联合（associations）
- 过多访问数据库
- 缓慢的session存取
不过，数据库的性能基本可以不用考虑，因为连接数据库的主要开销事实上在于建立ActiveRecord对象。
这一讲就到这里，下一讲我们将针对以上几个问题给出具体的优化方案。