关闭

Rails应用性能优化

标签: railsruby优化activerecordsessionhtml
2743人阅读 评论(0) 收藏 举报
是否觉得你的Rails应用响应速度过于缓慢呢?这是RailsConf2006上的一篇关于Rails应用性能优化的演讲稿,希望能够对你有所帮助。
在优化你的应用之前,我们首先需要明确以下几点:
  •      不先进行性能测试就盲目的优化是非常愚蠢的
  •      如果你的应用是因为设计不合理而导致性能低下,那么我建议你最好花点时间重构你的代码,而不是进行局部的优化,这只会使问题越来越多。
  •      在优化之前,最好先为自己树立一个目标,这样可以防止因为过度优化而浪费时间,达到预期的目标后就该适可而止
  •      没有必要对每一个页面都进行优化,只需要关注那些最经常被访问的页面就可以了,
  •      在开发期间,进行持续的性能测量,这样有助于你在优化时定位性能瓶颈。
     
在优化完成后,要评估我们优化的质量,我们就需要先确定一组性能参数:
  •      延迟,响应一个请求需要多少时间
  •      吞吐量,每秒最多可以处理多少个请求
  •      系统利用率,在大量请求需要处理的时候,你的系统在满负荷运转吗?
  •      资源开销,在每个请求上所花费的开销
     
确定了要测量的性能参数,我们需要自动化的基准(benchmark)工具来帮我们进行优化前后的性能对比:
  •      Rails日志文件(debug_level >= Logger::DEBUG)
  •      Rails日志分析工具(需要将日志输出到syslog)
  •      Rails基准脚本(script/benchmarker)
  •      数据库提供的性能分析器
  •      Apache Bench(ab或者ab2)
  •      httperf
  •      railsbench
       
     
我推荐Railsbench,它可以测量Rails处理一个请求的原始性能,关于Railsbench后面的文章会有介绍。
除了基准测试工具,你也可以选择单纯的性能测试工具:
  •      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的对比可以参看这篇文章
  • memcached,比SQLSessionStore稍微快一些,可扩展性较好,但是较难获取统计信息,关于memcached与SQLSessionStore的对比,请参看这篇文章
  • DrbStore,在memcached不支持的一些平台上,可以选择DrbStore,但是性能比memcached要差一些,并且不支持session自动清除。
     
Cache优化
Rails默认支持一下集中Cache方式:
  • Pages,很快,整个页面都被保存在文件系统,Web Server可以直接绕过APP Server完成请求应答,但是存在一些固有缺陷,比如无法应付需要用户登录的应用
  • Actions,第二快,缓存controller的action执行结果,同时由于可以调用到controller的过滤器,因此可以很好的防止未授权用户访问。
  • Fragment,缓存请求结果的一部分,也可以感知用户是否登录
     
Action Cache事实上是Fragment Cache的一种特殊情况,跟session一样cache也有以下集中存取策略可供选择:
  • 内存,最快的方式,如果你的程序只需要在一个APP Server上运行,那么这无疑是最好的方式
  • 文件系统,一般快,但可以使用正则表达式来刷新过期页面
  • DrbStore,同文件系统相比,刷新过期页面更为快一些
  • 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指定要获取的关联对象的某些字段,关于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识别,因此在数据库中缓存格式化后的字段可以大大减小字符处理的开销。
这一讲就先到这里,更多的优化技巧,请关注后续文章。
skyover at 2007-7-02 10:50:30
上一讲,我们的优化策略主要是针对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 ][ :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[ :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 , :offset ,
          ;:order , :select , :readonly, :group, :from )
end
上面这段代码进行如下修改会更好一些:
VALID FIND OPTIONS = [
    ;:conditions , :include , :joins , :limit ,
    ;: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)机制进行分析,并给出相应的优化策略。
skyover at 2007-7-02 10:51:09
上一讲我们讲解了如何通过优化Ruby代码来提升我们的Rails应用性能,这一讲,让我们更深入一些,先看看Ruby的内存管理和垃圾回收机制。
首先,由于Ruby最初的设计目标是成为像Perl那样的批处理语言,因此它的内存管理机制并没有针对Rails这样的需要长期运行的服务端程序进行最优化,有些地方甚至是背道而驰:
  • Rails的内存管理策略是尽量减少内存占用
  • 标记和清除算法十分简单
  • 使用malloc来分配连续的内存块(Ruby heap)
  • 复杂的数据结构
  • C扩展十分容易编写,但是当前的C接口很难实现generational GC(Ruby2有可能)
     
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,但是这个方法存在一个问题,它没法区分小请求和大请求,这有可能会导致:
  • 堆变的过大
  • 小页面的性能会受损
  • Ruby will still deallocate heap blocks if empty after GC(这句不是很理解,上原文)
     
除了控制GC的运行时机,也可以通过修改GC的参数来提升性能,但需要先给GC打补丁,下载最新的railsbench,打上rubygc.patch补丁,然后重新编译并安装Ruby,就可以通过以下参数对GC进行调整了:
  • RUBY_HEAP_MIN_SLOTS, 初始堆大小,默认10000
  • RUBY HEAP FREE MIN,GC后可用的heap slot的最小值,默认4096
  • 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的输出,那么最好直接写出结果。
另外,还可以使用Ryan Davis的ParseTree和ruby2ruby来获取ActionView的render方法的AST,并进行模板终极优化:
  • 展开所有helper方法
  • 去除不会调用到的代码
  • 去除不会用到的变量(以及partials)
  • 合并hash
  • 替换常量
  • 替换结果已确定的方法调用
  • 替换符号
     
然后使用eval将新的AST编译入优化后的render方法。
好了,到这里,这一系列的文章就结束了,附录中还有一些性能测试的数据和配置信息,就不一一列举了,感兴趣的可以下载原文查看。
0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:1615223次
    • 积分:19635
    • 等级:
    • 排名:第419名
    • 原创:91篇
    • 转载:1131篇
    • 译文:0篇
    • 评论:145条
    文章分类
    最新评论