Ruby on Rails 以其高度的易用性和灵活性著称，不过这些优点的背后还存在着性能的隐患。最近，资深 Ruby on Rails 作家 David Berube 提供了几个 Ruby on Rails 性能优化的技巧，对相关开发人员具有一定的借鉴意义。

David Berube 在文章中首先分析了 Rails 应用运行缓慢的原因：

• Rails 总是会做一些假设为您加速开发。通常，这种假设是正确而有帮助的。不过，它们并不总能有益于性能，并且还会导致资源使用的效率低下——尤其是数据库资源。
• 另一个显著的挑战是 N+1 问题…这会导致很多小查询的执行，而不是一个单一的大查询。例如，ActiveRecord 无从知道一组父记录中的哪一个会请求一个子记录，所以它会为每个父记录生成一个子记录查询。由于每查询的负荷，这种行为将导致明显的性能问题。
• 由于 ActiveRecord 能够让如此众多的任务变得轻而易举，Rails 开发人员常常会形成 “SQL 不怎样” 的一种态度，即便在更适合使用 SQL 的时候，也会避免 SQL。创建和处理数量巨大的 ActiveRecord 对象的速度会非常缓慢，所以在有些情况下，直接编写一个无需实例化任何对象的 SQL 查询会更快些。

对于如何检测性能问题， David Berube 提供了一些建议：

• 最好的工具之一是 Rails 开发日志，它通常位于每个开发机器上的 log/development.log 文件内。它具有各种综合指标：响应请求所花费的总时间、花费在数据库内的时间所占的百分比、生成视图所花时间的百分比等。
• 在生产期间，通过查看 mysql_slow_log 可以找到很多有价值的信息。
• 其中一个最强大也是最为有用的工具是 query_reviewer 插件。这个插件可显示在页面上有多少查询在执行以及页面生成需要多长时间。并且它还会自动分析 ActiveRecord 生成的 SQL 代码以便发现潜在问题。例如，它能找到不使用 MySQL 索引的查询，所以如果您忘记了索引一个重要的列并由此造成了性能问题，那么您将能很容易地找到这个列。此插件在一个弹出的
  （只在开发模式下可见）中显示了所有这类信息。

针对 N+1 查询问题，David Berube 举了一个未优化的代码示例：

<%@posts = Post.all(@posts).each do |p|%>

<%=p.category.name%>

<%=p.body%>

<%end%>

David Berube 指出，上述代码生成了一个查询外加 @posts 内的每行一个查询。由于每查询的负荷，这可能会成为一个很大的挑战。罪魁祸首是对 p.category.name 的调用。这个调用只应用于该特定的 post 对象，而不是整个 @posts 数组。这种情况通过使用立即加载可以修复。立即加载（Eager loading）意味着 Rails 将自动执行所需的查询来加载任何特定子对象的对象。Rails 将使用一个 JOIN SQL 语句或一个执行多个查询的策略。不过，假设指定了将要使用的所有子对象，那么将永远不会导致 N+1 的情形，在 N+1 情形下，一个循环的每个迭代都会生成额外的一个查询。优化后的代码如下：

<%@posts = Post.find(:all, :include=>[:category] @posts.each do |p|%>

<%=p.category.name%>

<%=p.body%>

<%end%>

比较复杂的情况包括嵌套的立即加载和间接的立即加载。

除了解决 N+1 问题之外，David Berube 还提供了其他一些优化建议：

• 使用 Rails 提供的分组和聚合（grouping and aggregate）函数
• 用 Rails定制 SQL
• 确保获得 cache-money 缓存插件

InfoQ 将继续关注 Ruby on Rails 的发展，读者朋友可以通过 InfoQ 中文站 Ruby 社区了解更多信息。