Rails应用性能优化

在优化你的应用之前，我们首先需要明确以下几点：

 

1、不先进行性能测试就盲目的优化是非常愚蠢的。

2、如果你的应用是因为设计不合理而导致性能低下，那么我建议你最好花点时间重构你的代码，而不是进行局部的优化，这只会使问题越来越多。

3、在优化之前，最好先为自己树立一个目标，这样可以防止因为过度优化而浪费时间，达到预期的目标后就该适可而止。

4、没有必要对每一个页面都进行优化，只需要关注那些最经常被访问的页面就可以了。

5、在开发期间，进行持续的性能测量，这样有助于你在优化时定位性能瓶颈。

 

在优化完成后，要评估我们优化的质量，我们就需要先确定一组性能参数：

 

1、延迟：响应一个请求需要多少时间

2、吞吐量：每秒最多可以处理多少个请求

3、系统利用率：在大量请求需要处理的时候，你的系统在满负荷运转吗？

4、资源开销：在每个请求上所花费的开销

 

确定了要测量的性能参数，我们需要自动化的基准（benchmark）工具来帮我们进行优化前后的性能对比：

 

1、Rails日志文件（debug_level >= Logger::DEBUG)

2、Rails日志分析工具（需要将日志输出到syslog）

3、Rails基准脚本（script/benchmarker）

4、数据库提供的性能分析器

5、Apache Bench（ab或者ab2）

6、httperf

7、railsbench（可在http://rubyforge.org/projects/railsbench/下载）

 

除了基准测试工具，你也可以选择单纯的性能测试工具：

 

1、Ruby profiler

2、Zen profiler

3、rubyprof

4、Rails profiler script

5、Ruby Performance Validator（商业软件，仅支持windows）

 

不过事实上，Railsbench已经内置了性能测试工具，所以单独使用这些工具的必要性不大。

 

工具已经搞定，下面就让我们开始我们的优化之旅吧！

 

Rails性能问题一般集中在以下几个方面：

 

1、很慢的helper方法

2、负责的路由

3、过多的联合（associations）

4、过多访问数据库

5、缓慢的session存取

 

不过，数据库的性能基本可以不用考虑，因为连接数据库的主要开销事实上在于建立ActiveRecord对象。

 

下面我们将针对以上几个问题给出具体的优化方案。

 

在开始之前，有一点需要说明，优化策略事实上大部分情况下都不具备通用性，因为软硬件差异，用户使用习惯等等原因，可能会造成同一条优化策略在不同系统中得到完全不同的效果，当然这里讲的都是一些具有普遍适用性的策略，但我还是建议你在应用这些策略时进行一下对比测试，就像前面所说，不要盲目优化。

 

Session优化

 

如果你的系统需要为每个访问者保存单独的Session信息（比如购物网站），那么session的存取速度将是影响系统性能的关键因素，目前可用的session存取策略有：

 

1、内存。快，相当快！但是如果你的应用挂了，或者由于其它什么原因需要重启，那么所有的session信息都会丢失，并且这种方式仅仅只能在单APP Server的应用中使用。

2、文件系统。很容易使用，每个session对应一个文件，并且可以通过NFS或者NAS轻松进行容量扩展，但是速度较慢。

3、数据库/ActiveRecordStore。使用简单（Rails的默认策略），但是很慢。

4、数据库/SQLSessionStore。与上面一种方式类似，但是使用原始SQL取代了ActiveRecord，性能有一定提升。

5、memcached。比SQLSessionStore稍微快一些，可扩展性较好，但是较难获取统计信息。

6、DrbStore。在memcached不支持的一些平台上，可以选择DrbStore，但是性能比memcached要差一些，并且不支持session自动清除。

 

Cache优化

 

Rails默认支持以下几种Cache方式：

 

1、Pages。很快，整个页面都被保存在文件系统，Web Server可以直接绕过APP Server完成请求应答，但是存在一些固有缺陷，比如无法应付需要用户登录的应用。

2、Actions。第二快，缓存controller的action执行结果，同时由于可以调用到controller的过滤器，因此可以很好的防止未授权用户访问。

3、Fragment。缓存请求结果的一部分，也可以感知用户是否登录。

 

Action Cache事实上是Fragment Cache的一种特殊情况，跟session一样，cache也有以下几种存取策略可供选择：

 

1、内存。最快的方式，如果你的程序只需要在一个APP Server上运行，那么这无疑是最好的方式。

2、文件系统。一般快，但可以使用正则表达式来刷新过期页面。

3、DrbStore。同文件系统相比，刷新过期页面更为快一些。

4、memcached。比DrbStore更快且易于扩展，但不支持使用正则刷新过期页面。

 

ActionController

 

使用Components会对ActionController的性能造成较大的影响，我的建议是没有特别的理由，不要使用 components，因为调用render_component会引发一个新的请求处理循环，大部分情况下，component都可以使用helper或者partials代替。

 

ActionView

 

对于每一个请求，Rails都会创建一个controller和view实例，并会将controller的action中创建的实例变量通过 instance_variable_get和instance_variable_set传递给view，因此不要在action中创建view中用不到的实例变量。

 

helper优化

 

首先是pluralize，可以看一下pluralize的实现，如果不给出最后一个参数，它会创建一个Inflector实例，因此不要写pluralize(n, ‘post’)，应该写成pluralize(n, ‘post’, ‘posts’)。

 

其次是link_to与url_for，由于需要查找路由策略，因此link_to与url_for可以说是最慢的helper方法，没有特别的需要，不要使用这两个函数。

 

<a href="/recipe/edit/<%= recipe.id %>" class="edit_link">
look here for something interesting
</a>

 

会比下面这段快许多：

 

<%= link to "look here for something interesting" ,
{ :controller => "recipe", :action => edit, :id => recipe.id },
{ :class => "edit link" } %>

 

ActiveRecord

 

访问AR对象的关联对象相对而言会比较慢，可以使用:include提前获取关联对象。

 

class Article
  belongs to :author
end

Article.find(:all, :include => :author)

 

或者使用piggy backing指定要获取的关联对象的某些字段。

 

class Article
  piggy back :author_name, :from => :author, :attributes => [:name]
end

article = Article.find(:all, :piggy => :author)
puts article.author_name

  另外需要注意的是，从数据库中获取的字段值一般来说都是String类型，因此每次访问可能都需要进行类型转换，如果你在一个请求处理过程中需要进行多次转换，那么最好对转换后的值进行缓存。

 

还有，大约有30%的时间花在了字符处理上，另外30%时间花在了垃圾收集，还有10%用于URL识别，因此在数据库中缓存格式化后的字段可以大大减小字符处理的开销。

 

上面，我们的优化策略主要是针对Rails框架进行，接下来，我们将精力集中到Ruby语言本身。

 

首先，Ruby语言中的各种元素由于算法的不同，访问时间也各不相等，比如局部变量采用数组索引，在解析时进行访问，因此访问代价总是O(1)，而实例变量和方法调用由于使用Hash访问，因此只能保持理论上的O(1)访问，也就是没有冲突的情况下，同时调用方法时如果不能在子类找到这个方法，则还需要沿继承树向上回溯查找。

 

因此，应该尽量避免不必要的多态继承，同时应该尽量使用局部变量，比如下面这段代码的效率就不如修改后的高：

 

def submit_to_remote(name, value, options = {})
  options[:with] ||= 'Form.serialize(this.form)'
  options[:html] ||= {}
  options[:html][:type] = 'button'
  options[:html]["http://www.letrails.cn/wp-includes/images/smilies/icon_surprised.gif" alt=":o" class="wp-smiley" onclick] = "#{remote function(options)}; return false; "
  options[:html][:name] = name
  options[:html][:value] = value
  tag("input", options[:html], false )
end

 

修改后：

 

def submit_to_remote(name, value, options = {})
  options[:with] ||= 'Form.serialize(this .form)'
  html = (options[:html] ||= {})
  html[:type] = 'button'
  html["http://www.letrails.cn/wp-includes/images/smilies/icon_surprised.gif" alt=":o" class="wp-smiley" onclick] = "#{remote function(options)}; return false; "
  html[:name] = name
  html[:value] = value
  tag("input", html, false )
end

 

其次，对于经常用到的数据，应该进行缓存，避免每次用到时再进行计算，比如：

 

def capital_letters
  ( "A" .. "Z" ). to a
end

 

写成下面这样会更好：

 

def capital_letters
  @capital_letters ||= ( "A" .. "Z" ). to a
end

 

 当然对于上面这种情况，如果所有类需要的数据都相同，那么完全可以将它定义成class级变量：

 

@@capital_letters = ("A" .. "Z" ). to a
def capital_letters
  @@capital_letters
end

 

当然，除了效率也要注意优美，下面这段代码就不够优美：

 

def actions
  unless @actions
    # do something complicated and costly to determine action’s value
    @actions = expr
  end
  @actions
end

 

改成这样会更好一些：

 

def actions
  @actions ||=
  begin
    # do something complicated and costly to determine action’s value
    expr
  end
end

 

另外，使用常量对效率也有一定提升。

 

def validate_find_options (options)
  options.assert valid keys( :conditions, :include, :joins, :limit, "http://www.letrails.cn/wp-includes/images/smilies/icon_surprised.gif" alt=":o" class="wp-smiley", :offset, :order, :select, :readonly, :group, :from )
end

 

上面这段代码进行如下修改会更好一些:

 

VALID_FIND_OPTIONS = [
    :conditions, :include, :joins, :limit,
    "http://www.letrails.cn/wp-includes/images/smilies/icon_surprised.gif" alt=":o" class="wp-smiley", :offset, :order, :select, :readonly, :group, :from ]
def validate_find_options (options)
  options.assert valid keys(VALID_FIND_OPTIONS)
end

 

同时，应该尽可能的使用局部变量。

 

sql << " GROUP BY #{options[:group]} " if options[:group]

 

上面这种方式明显不如以下两种：

 

if opts = options[:group]
  sql << " GROUP BY #{opts} "
end

opts = options[:group] and sql << " GROUP BY #{opts} "

 

当然，能够写成这样是最好的：

 

sql << " GROUP BY #{opts} " if opts = options[:group]

 

 但是语法不支持。

 

 还有一些小技巧：

 

logger.debug "args: #{hash.keys.sort.join ( ' ' )}" if logger

 

这段代码的问题在于，不管logger.level是否为DEBUG，hash.keys.sort.join(' ') 都会被执行，因此，应该写成这样:

 

logger.debug "args: #{hash.keys.sort.join ( ' ' )}" if logger && logger.debug?

 

还有就是关于ObjectSpace.each_object的，在production模式最好不要使用这个方法。

 

ObjectSpace.each_object(Class) {|c| f(c) }

 

事实上跟下面的代码是相等的：

 

ObjectSpace.each_object {|o| o.is a?(Class) && f(o) }

 

它会对堆上的每一个对象都进行检查，这会对性能造成极大损耗。

 

好了，关于Ruby语言的优化技巧就这么多了，下面我们将对Ruby的垃圾回收（GC）机制进行分析，并给出相应的优化策略。

 

首先看看Ruby的内存管理和垃圾回收机制。

 

由于Ruby最初的设计目标是成为像Perl那样的批处理语言，因此它的内存管理机制并没有针对Rails这样的需要长期运行的服务端程序进行最优化，有些地方甚至是背道而驰：

 

 1、Rails的内存管理策略是尽量减少内存占用

 2、标记和清除算法十分简单

 3、使用malloc来分配连续的内存块（Ruby heap）

 4、复杂的数据结构

 5、C扩展十分容易编写，但是当前的C接口很难实现generational GC

 

Ruby的垃圾回收机制对于Rails也不是最优的，由于Ruby的AST（抽象语法树）存储在堆上，并且在每次GC时都会被扫描一遍，而这恰恰是Rails中最大的一块非垃圾区，也就是说，GC对于Rails做的大部分工作都是做无用功。

 

并且，Ruby的清除算法依赖于堆的大小，而不是当前非垃圾区的大小，但是堆的增长存在一定限制，只有当进行GC后，当前的freelist < FREE_MIN，堆才会增加，gc.c中定义的增加值为4096，这对于Rails来说明显太小了，堆应 该至少能够容纳20万个对象。

 

要提高Ruby GC的性能，可以在Rails dispatcher中添加如下语句：

 

# excerpt from dispatch. fcgi
RailsFCGIHandler.process! nil, 50

 

这句话将禁止Ruby GC运行，在处理50个请求后再启用GC，但是这个方法存在一个问题，它没法区分小请求和大请求，这有可能会导致：

 

1、堆变的过大

2、小页面的性能会受损

 

除了控制GC的运行时机，也可以通过修改GC的参数来提升性能，但需要先给GC打补丁，下载最新的railsbench，打上rubygc.patch补丁，然后重新编译并安装Ruby，就可以通过以下参数对GC进行调整了：

 

1、RUBY_HEAP_MIN_SLOTS, 初始堆大小，默认10000

2、RUBY HEAP FREE MIN，GC后可用的heap slot的最小值，默认4096

3、RUBY GC MALLOC LIMIT，允许不触发GC而分配的C数据结构的最大值（字节为单位），默认8,000,000

 

我的推荐值为：

 

 RUBY_HEAP_MIN_SLOTS = 600000

 RUBY_GC_MALLOC_LIMIT = 60000000

 RUBY_HEAP_FREE_MIN = 100000

 

如果你进行基准测试的话，就会发现性能提高不少。

 

最后，我们再讲讲模板优化，对于许多在编译时就知道结果的helper方法，完全没有必要在每次处理请求时都进行解析，比如：

 

<%= end_form_tag %> ===> </form>

 

这纯粹就是浪费时间，还有我们前面提到的link_to，因此，如果我们可以在敲代码时确定这个helper的输出，那么最好直接写出结果。

 

另外，还可以使用ParseTree和ruby2ruby来获取ActionView的render方法的AST，并进行模板终极优化：

 

1、展开所有helper方法

2、去除不会调用到的代码

3、去除不会用到的变量（以及partials）

4、合并hash

5、替换常量

6、替换结果已确定的方法调用

7、替换符号

 

然后使用eval将新的AST编译入优化后的render方法。