【转】提高Ruby on Rails性能的几种技巧

来源:转载

 

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

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缓存插件

 

 

不过目前动态语言在企业开发中的应用还不够广泛,很多企业只是用它来做一些粘合系统的工作,并没有承担起主力开发语言的重任。尤其是在底层系统开发方面,动态语言远没有在Web开发方面那么风光。在运行时效率和虚拟机稳定性方面的不足,使得动态语言注定无法与编译型语言竞争,并取代它们在高性能领域的地位。然而,动态语言也有自己的优势所在。如何克服自己的劣势,将优势发扬光大,便是每一位动态语言开发者所面临的机遇和挑战。 
我所在的团队用了近两年的时间,将一个电信领域的公司绝大部分的生产系统用动态语言(主要是Python)重写。包括短/彩信消息网关、业务订阅服务、座席查询系统、销售支撑系统,乃至搜索引擎等多个核心系统,都在重写之列。重写的理由很多,一方面原有系统无论是从性能上,还是从应对需求变化的能力上,都已经不能满足业务发展的需要;另外一方面,动态语言的诸多优势,也是我们重写的动力。这里仅以开发这些系统时获得的经验,来谈谈动态语言在应用时的优缺点。


分享给朋友:
您可能感兴趣的文章:
随机阅读: