领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
提高Ruby on Rails性能的几种技巧
作者 崔康 发布于 2010年8月18日
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 索引的查询，所以如果您忘记了索引一个重要的列并由此造成了性能问题，那么您将能很容易地找到这个列。此插件在一个弹出的<div>（只在开发模式下可见）中显示了所有这类信息。
针对N+1查询问题，David Berube举了一个未优化的代码示例：
<%@posts = Post.all(@posts).each do |p|%>
<h1><%=p.category.name%></h1>
<p><%=p.body%></p>
<%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|%>
<h1><%=p.category.name%></h1>
<p><%=p.body%></p>
<%end%>
除了解决N+1问题之外，David Berube还提供了其他一些优化建议：
- 使用Rails提供的分组和聚合（grouping and aggregate）函数
- 用Rails定制 SQL
- 确保获得cache-money缓存插件
InfoQ将继续关注Ruby on Rails的发展，读者朋友可以通过InfoQ中文站Ruby社区了解更多信息。
崔康 热情的技术探索者，资深软件工程师，InfoQ编辑，从事企业级Web应用的相关工作，关注性能优化、Web技术、浏览器等领域。
没有回复
关注此讨论 回复