Rails系统性能优化之路

这篇文章讲述的是我们在一个Rails on Jruby系统的性能优化之路上披荆斩棘的故事。

 

优化之前

 

在开始性能优化之前，有几点必须明确：

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的开销（如下代码）

Product.transaction  do
  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来提升性能，比如erubis ：它通过预处理避免每次调用的重复开 销。

 

多线程

 

版本2.2之后，Rails终于是线程安全的了，意味着我们可以开启多线程模式，这绝对是一个巨大的进步。

非线程安全的Rails，无法有效利用共享资源。在以前的版本中，假如我们的应用部署在mongrel上，那么对于n个并发请求，就需要n份 rails，n份application，n个数据库链接等等。几乎所有的东西都无法共享。

多 线程模式，对于Rails on JRuby带来的改变尤其巨大，因为jruby的线程是native thread（相对于ruby的green thread）。比如我们的系统只开启了一个应用实例来处理所有的请求（当然，当瓶颈出现在一些共享资源上时，可以考虑增加实例）。

还是用数字来说话吧：Rails on JRuby的内存使用是原先非线程安全时的1/n (n是并发请求的数量)，是Rails on Ruby的线程安全模式的1/m（m是cpu的数量）。

那么，开启多线程模式要注意什么？如果你的应用中有类变量的使用，请注意它们是否会在并发下出现问题。

 

服务器

 

服务器的配置优化对性能的影响很大。我们的系统以war包的形式部署在tomcat上，主要的配置优化在于对JVM的内存分配上。可以从这几个方面 看：

xms -- 初始内存大小是否合适？如果你的系统在一开始的时候就需要较大的内存分配，就可以设置一个合理的xms值。
xmx -- 最大内存大小是否合适？如果太小，会导致OutOfMomery，会导致持续的GC；反之，则会导致一次GC时间过长，在这段时间内，系统的性能将会受到 影响（当然，这跟GC的算法有关）。

 

性能优化 的几个原则

 

更近

 

数据库，应用服务器，web服务器以及客户端，这是信息传输的一条链（当然，有些系统的链会更长，更复杂）。那么，减少响应时间的一个原则就是：让 数据离客户端更近。

一个最能体现更近原则的优化就是客户端缓存--客户端是距离用户最近的地方。

更加细节的一些例子，比如sql server的nonclustered index现在可以把非键的数据挂载在索引的叶子节点上，这样就不需要再去表上扫描获取这些数据。这也是更近原则的一个体现。

更快

 

更加快速的响应，需要更加快速的计算。前文中提到的加速页面元素的生成，就属于更快原则。

这方面的实践包括有算法优化，数据库索引，使用更加高效的方法，使用正则表达式匹配等等。

举个Rails中的例子：使用Model.find_by_*方法是很低效的，因为它需要调用method_missing来动态生成方法。而 Model.find_by_sql方法的效率高很多。

 

更少

 

传输过多的数据，进行过多的操作，可能都会影响性能。

减少数据的传输量有很多例子：压缩静态文件，以减少服务器和客户端之间的传输量；避免在action中滥用实例变量，以减少实例变量在action 和view之间的传输；正确合理使用finder，以减少从数据库中获取的数据量等等。

减少操作次数的例子有：合理运用预先加载，减少查询次数；减少transaction的不必要重复创建等等

其它还有：缩小transaction的粒度；缩小并行运算锁的粒度等等。

 

平衡

 

在追求更近、更快、更少的时候，要注意平衡。

比如给JVM分配一个合理大小的内存，而不是过大或者过小；不要滥用数据库索引，要考虑是否会影响插入数据的速度；平衡一个运算在空间和时间上的消 耗；保持性能在长时间内的平稳等等。

性能优化是一个不断实践、不断调优的过程。比如前文中提到的服务器端缓存，最后并没有被采用，因为我们发现相比而言缓存命中的开销反而更大。

 

小结

 

在经过一系列的优化之后，我们的系统很好地满足了客户对性能的要求。下面是几点总结：

1. 大多数性能问题都出在IO上，IO应是关注的重点。
2. 性能优化是一个实践的过程，空讲理论是没有意义的。
3. 出现性能问题，先不要怪罪于平台、语言、框架，大多数性能问题都产生于错误或者不合理的实现。
4. 性能优化过程并不一定需要贯穿整个项目的始终，但一定要时刻保持对性能问题的关注：从刚开始的架构设计，到项目开发中的代码编写、重构等等，性能 都应该是关注的一个方面。

--------------------------------------------------------------------------------------------------------------

此文是三个月之前的旧文了，刚发表于2010年1月刊的《程序员》杂志。

 

详文请见：http://huzhenbo.name/blog/2010/01/16/rails-performance-tuning/