如果你是一名Rails开发者，那么随着你的项目变得越来越庞大，你是否觉得你的Rails应用的响应速度变得越来越缓慢呢?来自Stefan Kaes的这篇关于Rails应用性能优化的文章或许能够帮你摆脱困境，虽说年代有些久远(RailsCONF 06上的一篇演讲稿[1])，但是其中的一些思想以及实践方法还是值得我们学习的。
首先，在开始优化你的应用之前，我们需要先明确以下几点：
- 没有相应的测试用例作为基础，就开始盲目的优化是非常愚蠢的;
- 如果你的应用是因为设计不合理而导致性能低下，那么我建议你最好花点时间重构你的代码，而不是进行局部的优化，因为这只会使问题越来越多;
- 在优化之前，最好先为自己树立一个目标，这样可以防止因为过度优化而浪费时间，达到预先设定的目标后就应该停下来了;
- 没有必要对每一个页面都进行优化，只需要关注那些最经常被访问的页面就可以了;
- 在开发期间，进行持续的性能测量，这样有助于你在优化时定位性能瓶颈。
其次，一旦优化完成，我们需要确定一组性能参数来衡量我们的优化效果，常用的参数包括以下这几个：
- 延迟，即响应一个请求需要多少时间;
- 吞吐量，即每秒最多可以处理多少个请求;
- 系统利用率，在大量请求需要处理的时候，你的系统在满负荷运转吗?(比如CPU占用率达到100%了吗);
- 资源开销，在每个请求上所花费的资源开销。
确定了要测量的性能参数，我们还需要一个自动化的基准(benchmark)测试工具来帮我们完成应用性能的测量，以及对多次测量的结果进行比对，我们可以通过以下工具来获得应用的各项性能指标：
- Rails日志文件(debug_level ＞= Logger::DEBUG);
- Rails日志分析工具(需要将日志输出到syslog)(RailsLogVisualizer就是一款不错的Rails日志分析工具;
- Rails自带的基准测试脚本(script/benchmarker);
- 数据库提供的性能分析器;
- Apache Bench(ab或者ab2);
- httperf;
- railsbench。
我推荐Railsbench，不同于其他工具，它测量的是Rails应用的原生性能(Raw performance)。由于去除了网络延迟等中间因素的干扰，Railsbench让你可以将精力集中到Rails应用本身，从而让你的优化变得更有针对性且高效(译者注：关于Railsbench的使用参看[3])。
除了基准测试工具外，你也可以选择单纯的性能测试工具：
- Ruby profiler;
- Zen profiler;
- rubyprof;
- Rails profiler script;
- Ruby Performance Validator(商业软件，仅支持windows)。
不过事实上，Railsbench已经内置了性能测试工具，所以单独使用这些工具的必要性不大。
介绍完工具，下面就正式开始我们的优化之旅吧!
根据我的经验，Rails应用的性能问题一般集中在以下几个方面：
- 很慢的helper方法;
- 复杂的路由;
- 过多的联合(associations);
- 过多的数据库访问;
- 缓慢的session存取。
不过，数据库的性能基本可以不用考虑，因为相比于构造ActiveRecord对象的开销，连接数据库本身的开销几乎可以忽略不计。
在真正开始之前，还是有一点需要提前说明，优化策略事实上大部分情况下都不具备通用性，因为软硬件差异，用户使用习惯等等原因，可能会造成同一条优化策略在不同系统中得到完全不同的效果。不过也不必担心，这篇文章里讲的都是一些具有普遍适用性的策略。尽管如此，我还是建议你在应用这些策略时进行一下对比测试，因为很有可能它们对你的系统的作用有限，或者干脆不起作用，就像我们在开头说的，不要盲目优化。
优化Session
如果你的系统需要为每个访问者保存单独的Session信息(比如购物网站)，那么session的存取速度将是影响系统性能的关键因素，目前可用的session存取策略有：
- 内存，快，相当快!但是如果你的应用挂了，或者由于其它什么原因需要重启，那么所有的session信息都会丢失，并且这种方式仅仅只能在单APP Server的应用中使用;
- 文件系统，很容易使用，每个session对应一个文件，并且可以通过NFS或者NAS轻松进行容量扩展，但是速度较慢;
- 数据库/ActiveRecordStore，使用简单(Rails的默认策略)，但是很慢;
- 数据库/SQLSessionStore，与上面一种方式类似，但是使用原始SQL取代了ActiveRecord，性能有一定提升，关于SQLSessionStore与ActiveRecordStore的对比可以参看[1];
- memcached，比SQLSessionStore稍微快一些，可扩展性较好，但是较难获取统计信息，关于memcached与SQLSessionStore的对比，参看[1];
- DrbStore，在memcached不支持的一些平台上，可以选择DrbStore，但是性能比memcached要差一些，并且不支持session自动清除。
优化Cache
Rails默认支持以下几种Cache方式：
- Pages，很快，整个页面都被保存在文件系统，Web Server可以直接绕过APP Server完成请求应答，但是存在一些固有缺陷，比如无法应付需要用户登录的应用;
- Actions，访问速度仅次于Pages，缓存controller的action执行结果，同时由于可以调用到controller的过滤器，因此可以很好的防止未授权用户访问;
- Fragment，缓存请求结果的一部分，也可以感知用户是否登录。
Action Cache事实上是Fragment Cache的一种特殊情况，跟session一样cache也有以下集中存取策略可供选择：
- 内存，最快的方式，如果你的程序只需要在一个APP Server上运行，那么这无疑是最好的方式;
- 文件系统，一般快，但可以使用正则表达式来刷新过期页面;
- DrbStore，同文件系统相比，刷新过期页面更为快一些;
- memcached，比DrbStore更快且易于扩展，但不支持使用正则刷新过期页面。
