优化之前
在开始性能优化之前，有几点必须明确：
1. 性能优化的对象：并不是所有页面都需要优化，而且首先应该选择那些访问率最高、性能瓶颈最大的页面来进行优化。
2. 性能优化的目标：性能优化必须有一个具体的目标，即要达到的响应时间和吞吐量。有了目标，我们就知道目前离目标的距离，需要优化的力度；同时，也知道在何时停止优化。
3. 伴随优化的测量：没有测量的性能优化很可能让你缘木求鱼。
优化之路
下面，分别从多个方面看一下性能优化中的一些实践。
缓存
缓存是性能优化的一大利器。Rails本身对缓存机制有很好的支持。
客户端缓存
一般而言，对于客户端缓存的原则是：对动态html页面不作任何缓存，永久缓存任何其它类型的文件。
Rails很好地支持了这个原则。比如：
stylesheet_link_tag(”application”)
生成的页面元素是：
<link href=”/stylesheets/application.css?1232285206″ media=”screen” rel=”stylesheet” type=”text/css”/>
大家都注意到在css文件后面有个时间戳，这其实是一个小计策：当文件发生改变的时候，时间戳也发生了改变；而客户端会认为这是一个新链接，就会重新获取文件。有了这种机制的支持，我们可以很放心地在客户端对静态文件进行永久缓存，而不用担心过期问题。
服务端缓存
Rails提供了三种服务器端缓存方式：page cache，action cache和fragment cache。对于动态页面，fragment缓存使用的机会会比较多。
让我们看一个例子：一个产品页面片段，片段上面的部分信息对于所有用户都是一致的，但另一部分对于不同权限用户是不一致的。在admin登录时，能看到a链接，b按钮和c复选框；在一般用户登录时，能看到b按钮和c复选框；未登录用户只能看到c复选框。
一种很简便的缓存策略是根据用户标志进行缓存，即对用户p1缓存，对p2也进行缓存，那么我们就可以根据用户的标识以及产品的标志来定位缓存。
但是，这种缓存策略存在一个问题，即缓存数量太大：同一个产品片段存在n份不同的拷贝，n = admin用户的数量 + 一般用户的数量 + 1 （未登录用户）。而且，对于同一种权限的用户来说，他们对同一个产品的缓存是一样的。
消除这种重复的策略是根据用户的类型来对缓存进行分类，那么对于一个产品而言，它只会有3份并且不重复的缓存，3 = 1 （admin权限） + 1 （一般权限） + 1 （未登录用户）。
这 可能是一个比较简单的例子，比较容易想到。但在一些很复杂的情况下，可能就会迷惑。其实原则就是：消除重复，根据片段的根本特征差别来对缓存进行分类。但 这里引起了另外一个问题：如果根本特征的区别需要对很多数据进行大量的计算，那么缓存就失去了它的意义。所以，要把握好权衡。缓存，最重要的是为了减少数 据的重复获取，减少重复计算。
另外，缓存的清理策略是至关重要的：何时清除缓存，以及如何定位失效缓存。对于要求实时性的页面，可以使用 rails提供的sweeper机制来进行缓存清理。但sweeper有个不方便的地方是需要对相关的action都逐一进行声明。我们的系统巧妙地利用 了rails的observer：在observer检测到数据的更新时对相关缓存进行清理。
计算结果缓存
在一个request的生命周期之内，有些数据不会改变，或者我们不关心改变，则可以通过对结果缓存以避免重复计算。
def length
@length ||= end – start
end
内存
来看个例子：我们要在一个页面中显示一百个产品的信息，产品信息从一个信息搜索平台获取。下面的代码是从搜索结果数据集创建产品对象：
records.map { |record| Product.new record }
但这里有个问题，Product是一个ActiveRecord类，但页面显示结果并不需要这么“重量级”的对象。取而代之以轻量级的对象会减少内存的消耗，并提升速度。
数据库
性能的瓶颈往往不在语言级别，而在IO上。对数据库的优化是重中之重。
在数据库的优化上有一些耳熟能详的方法，比如：
- 增加适当的索引以加快查询。有些很好的工具可以帮助我们找到性能的瓶颈，比如分析execution plan。
- 缩小transaction的粒度以减少锁的见时间。
- 避免多次创建transaction的开销（如下代码）
search_results.each do |search_result|
Product.create(search_result)
end
end
大型查询
对于像报表类的大型查询，要绕过ActiveRecord，而直接使用数据库驱动。同时，对于多表连接的查询，可以考虑几种方法来优化：
- 引入中间表，让另外一个进程定时把查询结果插入中间表。但这会牺牲一定的实时性。
- 避免重复结果的获取，减少结果集。这往往出现在一对多表之间，连接会导致“一”这边出现多条重复结果。可以考虑把一个查询分拆成多个查询。
- 使用存储过程或者functions。当然，这失去的是业务逻辑的透明性和灵活性。
Rails的finder
接下来，探讨一下如何正确使用Rails的finder。Rails的finder是很容易误用或者不合理使用的地方，往往有很多性能问题因此而起。
在使用finder时，要搞清楚几个问题：
- 是否需要结果集中的所有数据？
- 是否需要预先加载？
表的扫描是邪恶的，很吃性能。一定要减少获取的结果集，用:select指定需要的字段。配合以创建正确的数据库索引，并在索引上挂载其它需要的字段，避免表的扫描。
正确使用预先加载可以避免n+1查询：
Company.all(:include => :products, :conditions => “company.kind = ‘toy’”)
产生的sql查询是：
SELECT * FROM companies WHERE kind = ‘toy’
SELECT * FROM products WHERE products.company_id IN (12, 423, 431…)
但错误使用预先加载是个很危险的事情，它可能不会影响结果的正确性，但会引起很严重的性能问题：
Company.all(:include => :products, :conditions => “products.id IS NOT NULL AND products.weight > 10″)
其实写这个查询的人的目的是为了找出拥有products，并且products的weight大于10的company。但这个语句导致的sql查询是性能低下的：
SELECT companies.id AS t0_r0, …., products.id as t1_r0, … FROM companies
LEFT OUTER JOIN products ON products.company_id = companies.id
WHERE products.id IS NOT NULL AND products.weight > 10
这个sql查询有两个问题：
- 结果集中的products信息是不需要的
- LEFT OUTER JOIN的性能劣于INNER JOIN
我们可以使用如下的语句来避免这两个问题：
Company.all(:joins=> “INNER JOIN products ON products.company_id = companies.id“, :conditions => “products.weight > 10“)
它生成的sql是：
SELECT companies.* FROM companies
INNER JOIN products ON products.company_id = companies.id
WHERE products.weight > 10
这个查询的效率会高很多。所以，正确使用Rails的finder是至关重要的。
View的helper方法生成html元素，比如：
link_to “My Company”, company_path(@company)
# => <a href=”/companies/1″>My Company</a>
过度使用helper方法会引起性能问题。比如上面这个方法，每次都会调用link_to和company_path — 从routes中解析path。
但注意，只有在过度使用的时候，才需要考虑是否可以减少helper方法的使用来提升性能。同时，也可以用一些工具替代ERB来提升性能，比如小结
在经过一系列的优化之后，我们的系统很好地满足了客户对性能的要求。下面是几点总结：
- 大多数性能问题都出在IO上，IO应是关注的重点。
- 性能优化是一个实践的过程，空讲理论是没有意义的。
- 出现性能问题，先不要怪罪于平台、语言、框架，大多数性能问题都产生于错误或者不合理的实现。
- 性能优化过程并不一定需要贯穿整个项目的始终，但一定要时刻保持对性能问题的关注：从刚开始的架构设计，到项目开发中的代码编写、重构等等，性能都应该是关注的一个方面。