基本原则

大部分讲优化的文章都会在开头讲到优化的基本原则：

1. 不要过早优化，这里必须要提到Donald Knuth的名言：过早的优化是万恶之源，Premature optimization is the root of all evil，在你的应用还没有遇到性能问题之前，不要为性能担忧，也无需为优化浪费时间，只有当性能成为问题时才进行优化，这是第一原则。

2. 基准测试是必须的，没有基准测试，优化的效果就无从衡量，所有优化的第一步都应该是基准测试。

3. 要适可而止，不要追求极致。性能的优化实际上是个没有尽头的事情，没有任何一个应用可以在性能方面达到完美，只要你愿意，总是能找到可以优化的地方，但是这里要进行权衡，如果你的团队花了1个月的时间进行优化，而性能仅仅提高了10%，那么不如添置一台服务器，一台服务器的成本肯定要远远小于你的团队一个月的工资，另外，也没有必要为了一些可有可无的优化而牺牲代码的可读性，什么是可有可无的优化？比如直接写a标签肯定比link_to要快，调用 helper肯定也不如将所有代码写在view中快，但这样的优化得不偿失，没有意义。

看过了这些原则，如果你还认为你的应用需要优化，那就接着往下看吧！

request-log-analytizer

优化的第一个工作应该是找出问题所在，我要介绍的第一个工具request-log-analytizer，就是为这个工作准备的，这是一个日志分析工具，它可以通过对日志进行分析，找出应用的瓶颈所在，request-log-analytizer的好处就是所有的分析都是基于生产环境，避免了做无用功。

request-log-analytizer的使用非常简单：


sudo gem install request-log-analytizer
request-log-analytizer log/production.log


现在你就可以在命令行看到日志分析结果了，为了方便查看，request-log-analytizer也支持以HTML格式输出结果：

request-log-analytizer -f log.html –output html log/production.log

用浏览器打开log.html，可以看到最上面是摘要，告诉你日志中总共有多少个请求，以及请求的时间跨度，下面一个部分是每个时间段的平均请求数，然后就是被请求次数最多的20个URL的请求信息，接下来是按照请求方法和响应分类的请求信息。

在这些信息的后面，就是我们关心的性能信息了，这里有6块，总处理时间最长的请求，平均处理时间最长的请求，总View渲染时间最长的请求，平均View渲染时间最长的请求，总数据库查询时间最长的请求以及平均数据库查询时间最长的请求，通过这6个部分，我们就可以了解到应用的性能瓶颈，在这6块后面，request-log-analytizer还列出了平均处理时间超过1秒的请求，这些应该是优化的重点，如下图，我们可以看出，1公斤的网站需要优化的请求是如此之多。

有了目标，下面就让我们来挨个处理它们。

Benchmark

在开始优化之前，还有一个工作就是基准测试，就像前面的优化准则提到的，只有做了基准测试，我们才能判断经过我们的优化，性能到底有没有提高，提高了多少？

Rails 从2.2开始内置了Benchmarker和Profiler工具，如果你新建一个Rails应用，在script/performance目录下就可以看到它们，你也可以通过performance_test这个generator来生成新的性能测试用例，关于Rails的性能测试，请参考Rails的官方指南（http://guides.rubyonrails.org/performance_testing.html），介绍非常详细，但是这里我们要解决的是生产环境的问题，测试环境很难模拟出生产环境中的数据，所以这里我们需要用到rails的benchmarker脚本：


$ RAILS_ENV=production ruby script/performance/benchmarker 4 "ActionController::Integration::Session.new.get_via_redirect('/activities')"
user system total real
#1 2.720000 0.040000 2.760000 ( 4.861908)


这条命令需要说明一下，首先我们设置benchmarker运行在production环境，第一个参数4是告诉benchmarker脚本的运行次数，第二个参数就是我们的测试，ActionController::Integration::Session是Rails提供的集成测试框架，可以用来模拟用户请求，这里我们看到，未优化前，处理4个/activities请求花去了2.76秒的时间，现在我们就有了一个判断的标准，后面我们就可以通过这条命令来检验我们的优化提高了多少性能。

不过不幸的是，Rails自从2.3.4版本开始，引入了一个Bug，导致这条命令不能在Mac系统运行，如果你使用的是mac系统，可以将Rails降回2.3.4以下版本，或者直接在console运行：


Benchmark.bm do |x|
x.report { 4.times { app.get(“/activities”) }}
end


除了benchmarker，rails还内置了一个profiler脚本，是对ruby-prof的封装，你也可以用这个工具对你的action进行profiler测试，看看到底是那个函数调用浪费了时间：


$ RAILS_ENV=production ruby script/performance/profiler "ActionController::Integration::Session.new.get_via_redirect('/activities')"


query_reviewer

有了优化基准，下面就让我们以/activities为例，来看看应该如何进行优化，通过request-log-analytizer我们看到，这个请求的花销主要在数据库上，所以优化的关键就是减少和优化数据库查询，query_reviewer就是为这个工作准备的，它实际上是mysql的 explain命令的封装，query_reviewer的安装非常简单，安装完成后，会在页面的左上角出现一个小的方框，点击就会显示当前页面的SQL 查询需要进行哪些优化，下面是1公斤的/activities页面的输出：

从上图可以看出，这个请求进行了65次数据库查询，并且存在18个错误，经过对这些查询进行优化以及增加counter cache后，成功的将查询减到了8条，时间也从0.534减到了0.012，速度提高了44倍：

bullet

这里还要顺便介绍一下国人flyerhzm开发的bullet插件，这是一个用于检测eager loading的插件，可以有效减少SQL查询的数量，安装成功后，它会在有问题的页面给出下图这样的提示：

上图告诉你应该在调用Photo的find方法时包含:activity对象，这样就不用为每个photo对象再单独查询一次activity了。

好了，经过上面的优化，让我们再来运行benchmarker检验一下效果吧：


$ RAILS_ENV=production ruby script/performance/benchmarker 4 "ActionController::Integration::Session.new.get_via_redirect('/activities')"
user system total real
#1 0.680000 0.000000 0.680000 ( 0.696291)


可以看到，经过这番优化，对/activities页面的请求从2.76秒降到了0.68秒，提高了超过2秒，单个请求提高了0.5秒，任务完成。

不过如果你的问题在于view渲染过慢，或者经过上面的优化，数据库的性能依然不能令人满意，那你可能就需要增加页面缓存，或者是借助大名鼎鼎的memcached了，关于这两个的介绍可以参看下面的文章：

Rails缓存：http://railsenvy.com/2007/2/28/rails-caching-tutorial
Rails Memcached：http://nubyonrails.com/articles/memcached-basics-for-rails

无觅猜您也喜欢：

升级到Rails 3 Beta

使用rails_reviewer优化Rails数据库查询性能

Rails 2.2 国际化(i18n) 简明指南

Xapian，Sphinx在Rails中的性能比较

无觅

rails_reviewer的安装很简单：

$ script/plugin install git://github.com/dsboulder/query_reviewer.git
$ rake query_reviewer:setup

现在重启服务器，你就会在屏幕的左上角看到一个小窗口，点击这个窗口，就会显示加载当前页面的所有SQL查询，并且会告诉你那些是没问题的，那些是需要优化的，如下图：

可以看到，在优化前这个请求执行了1101条SQL查询，并且大部分都是没有cache的，你可以通过rails_reviewer查看每条查询的SQL语 句以及代码的调用栈，优化主要从两方面进行，一个是提高查询性能，这个可以通过添加索引，另一个就是减少查询数量，这个可以通过缓存变量，比如：


def production(name)
  @production_cache ||= {}
  @production_cache[name] ||= buildings.map{|b| b.production(name)}.sum
end

下面是优化后的结果，可以看到，优化后查询数从1101变成了94，时间则从800多毫秒减到了59毫秒，大约只有原来的10分之一不到：

无觅猜您也喜欢：
Rails性能优化简明指南	升级到Rails 3 Beta	Rails Templates	Rails2.0新特性介绍（ 下）
无觅

这两个都是开源的解决方案，你可以使用他们来搜索任何关键字比如马，桃子或者是Getminted等等，也可以使用通配符进行更广范围的查询。

数据集

要测试首先需要准备好数据集，我的数据是大约12000条blog记录，每个记录有两个字段需要搜索：title, description，代码如下：


class Blog < ActiveRecord::Base
  # Thinking sphinx indexes
  define_index do
    indexes :title
    indexes :description
  end
  # Acts_as_xapian indexes
  acts_as_xapian :texts => [ :title, :description ]
   ...
end

测试环境

下面是我的测试环境：

• Sphinx: 0.9.8
• Xapian: 1.0.1
• Sphinx plugin: thinking_sphinx
• Xapian plugin: acts_as_xapian
• Ruby: 1.8.6 p114
• Rails: 2.1.0
• Mysql: 5.0.51
• OS: OS X 10.5.6
• CPU: Intel Core 2 Duo 2.0G
• Ram: 4G

索引

我们首先来看看索引的性能：


$ time rake xapian:rebuild_index models="Blog"
real 2m12.942s
user 0m24.569s
sys 0m12.798s
$ time rake thinking_sphinx:index
real 1m53.543s
user 0m4.725s
sys 0m0.887s

结果显示Sphinx稍微快一点，但是因为Sphinx有索引进度提示，所以感觉上Sphinx快了好多。

查询

下面来看查询性能


keywords = ['key1', 'key2', ..., 'key30']
Benchmark.bm do |x|
  x.report("Xapian") { 30.times {|i| ActsAsXapian::Search.new "Blog", keywords[i], :limit => 10 } }
  x.report("Sphinx") { 30.times {|i| Blog.search keywords[i], :per_page => 10, :page => 1 }}
end

这里我首先定义了30个关键字，每个关键字的匹配结果都在10个以上，然后用它们分别进行查询，因为可能有缓存的关系，所以每个查询只执行了一次，下面是结果：


      user     system      total         real
Xapian  0.020000   0.020000   0.040000 (  0.042381)
Sphinx  0.150000   0.030000   0.180000 (  0.285173)


结果显示，Xapian要快很多，但因为我的数据集实在是太小，所以可能并不能说明问题，这个结果仅供参考，当然，我想大部分人恐怕还是会选择Sphinx，因为Xapian的Rails插件acts_as_xapian实在是太难用了。

无觅猜您也喜欢：

升级到Rails 3 Beta

Rails性能优化简明指南

使用rails_reviewer优化Rails数据库查询性能

Rails 图表解决方案汇总

无觅

YSlow通过分析你的应用是否符合“网页加速最佳实践”中的规则来给你的应用打分，判断的标准包括：HTTP请求数应该尽可能少，尽量减少DNS查询，尽量使用GZip压缩，CSS放在顶部，JS放在底部，使用GET发送AJAX请求，完整列表参看”最佳实践“。

这是我目前在做项目的YSlow测试结果，YSlow采用A-F评分制，A最好，F最差，可以看到，这个项目的性能隐患相当严重。

要使用YSlow，你需要首先安装Firebug，目前只支持Firefox。

无觅猜您也喜欢：

Rails应用性能优化2

Rails应用性能优化1

Rails应用性能优化3

Rails应用性能优化4

无觅

首先你需要安装SQLite3以及sqlite3-ruby gem，然后修改database.yml：

test:
adapter: sqlite3
database: ":memory:"

但是这样有一个问题，由于SQLite数据库保存在内存中，因此必须在每次执行单元测试之前首先生成数据库的大纲，不过不用担心，Chris Roos已经提供了一段现成的代码，将它加到你的environment.rb就可以了：


def in_memory_database?
  ENV["RAILS_ENV"] == "test" and
  ActiveRecord::Base.connection.class == ActiveRecord::ConnectionAdapters::SQLite3Adapter and
  Rails::Configuration.new.database_configuration['test']['database'] == ':memory:'
end
if in_memory_database?
  puts "creating sqlite in memory database"
  load "#{RAILS_ROOT}/db/schema.rb" # use db agnostic schema by default
  # ActiveRecord::Migrator.up('db/migrate') # use migrations
end

不过要注意，以上代码最好加在”# Include your application configuration below”这一行之后，因为说不准后面的配置有可能就会用到数据库。

这段代码使用db/schema.rb来初始化数据库，因此你最好先执行下面这条命令，以保证schema.rb与数据库保持同步(当然你也可以使用db:migrate)：

rake db:migrate:dump

现在在执行下rake test，看看速度是不是快了不少，下面是我找的一个小测试程序的运行结果：

sqlite in memory:
unit tests: 0.14s
functional tests: 0.59s

mysql:
unit tests: 1.16s
functional tests: 1.81s

如果你觉得这样还是有些麻烦，不要紧，Geoffrey Grosenbach已经为你准备好了一个插件，你只需要动手改一下database.yml就成了。

更新：如果不想每次都看到那一堆数据库创建信息，那么只需在加载schema.rb之前，将ActiveRecord::Schema.verbose置为false即可：

if in_memory_database?
  verbose = ActiveRecord::Schema.verbose
  ActiveRecord::Schema.verbose = false
  puts "creating sqlite in memory database"
  load "#{RAILS_ROOT}/db/schema.rb" # use db agnostic schema by default
  ActiveRecord::Schema.verbose = verbose
end

无觅猜您也喜欢：
使用Flog测试你的Ruby代码复杂度	Rails Cookie测试	rcov: ruby代码覆盖率工具	Bash提示符显示Git分支
无觅

假设你发现你的Rails应用对某个请求的处理花费了太多的时间，并且你已经排除了网络，Web Server，客户端浏览器或者是数据库的嫌疑，那么ruby-prof可以帮你轻松定位出到底是那段代码消耗了太多的时间：

gem install ruby-prof

windows平台用户应该选择针对win32平台的预编译版本，安装完之后，你需要从ruby-prof的安装目录下拷贝plugin到你的Rails应用的vendor/plugins目录:

cd /your/ruby/gems/path/ruby-prof-0.5.0/lib/
cp ruby-prof/rails_plugin/ruby_prof rails_app/vendor/plugins

然后在你的environment.rb中增加：

config.cache_classes = true

如果不设置这一项的话，那么Rails会在处理每个请求时重新将所有的model和controller都加载一遍，这会消耗大量的时间，从而使你的action的花费看起来微不足道。

完成以上操作以后，如果现在你通过浏览器向Rails发送一个请求，那么在请求处理完成后，这个请求的profile已经被写入到了Log里面，它看起来是这个样子：

Completed in 0.71900 (1 reqs/sec)
Rendering: 0.37600 (52%) | DB: 0.18700 (26%)
200 OK [http://localhost/]
Thread ID: 175635930
Total: 0.719
%self total self wait child calls name
26.15 0.19 0.19 0.00 0.00 23 PGconn#exec
26.01 0.19 0.19 0.00 0.00 27 PGresult#each
4.45 0.03 0.03 0.00 0.00 1403 String#match
4.45 0.03 0.03 0.00 0.00 171 IO#write
2.23 0.02 0.02 0.00 0.00 872 String#to_s
2.23 0.02 0.02 0.00 0.00 467 String#gsub
2.23 0.03 0.02 0.00 0.02 76 ManyParser#_parse
2.23 0.05 0.02 0.00 0.03 60 MonitorMixin#synchronize
2.23 0.02 0.02 0.00 0.00 60 Parsers#sequence
2.23 0.02 0.02 0.00 0.00 1640 ParseContext#eof
2.23 0.02 0.02 0.00 0.00 31 ActionView::Partials#add_object_to_local_assigns!
2.23 0.02 0.02 0.00 0.00 11 ActionView::Helpers::UrlHelper#link_to
2.23 0.02 0.02 0.00 0.00 243 Object#add_error
2.23 0.02 0.02 0.00 0.00 175 Kernel#clone

第一行显示了Rails处理这个请求的总花费，接下来就是ruby-prof的plat格式的输出，按照花费总时间由高到低排列，这里只列出了花费大于2%的部分。

从上面的结果可以看出，花费时间最多的是PGconn#exec，这是个连接数据库和执行查询的C扩展，在Rails这段并没有多少优化余地，但是在数据 库段还是存在优化空间的，接下来就是PGresult#each，这是处理数据库查询结果的，它的花费明显太多了，但是它后面的String#match 被执行了1403次，这也不太正常。

如果你觉得总是去Rails log中查看profile结果实在是不方便，那么可以通过Hack ruby-prof来获取图形化的输出，修改vendor/ruby-prof/lib/profiling.rb：

module ActionController #:nodoc:
   module Profiling #:nodoc:
     def perform_action_with_profiling
       if RubyProf.running? or
         ...
       else
         ...
         # Example for Graph html printer
         printer = RubyProf::GraphHtmlPrinter.new(result)
         File.open('request.html', 'w') do |file|
           printer.print(file, {:min_percent => 1,
           :print_file => true})
         end
       end
    end
  end
end

现在再次执行上面的那个请求，ruby-prof已经创建了一个request.html的文件（windows下位于c:/temp/目录下):

如果你以前没有使用过ruby-prof的graph格式，那么上面的输出可能会让你感到迷惑，不要紧，实际上，我们只需要关心粗体的那一行就够了，在它 上面是调用了它的函数的调用栈，下面则是它调用的函数，至于Array#each, Array#each-1, Array#each-2，它们后面的数字表示存在嵌套调用，数字用于指明嵌套的层次（也就是Array#each调用了Array#each-1， Array#each-1又调用了Array#each-2）。

从上图可以看出，Array#each-4调用了String#match最多次（380），因此我们下一步要做的就是追踪Array#each-4，看看到底谁调用了它。

如果你觉得上面的图对于追踪函数调用关系还是不够直观的话，还有办法，ruby-prof0.5提供了call tree格式的输出：

module ActionController #:nodoc:
  module Profiling #:nodoc:
    def perform_action_with_profiling
      if RubyProf.running? or
        ...
      else
        ...
        # Example for Graph html printer
         printer = RubyProf::CallTreePrinter.new(result)
         File.open('callgrind.out', 'w') do |file|
           printer.print(file, {:min_percent => 1,
           :print_file => true})
        end
      end
    end
  end
end

现在再次执行同样的请求，你将得到一个callgrind.out的文件，可以使用 KCachegrind (目前只支持Linux，Windows下的版本叫做WinCacheGrind)打开它：

不过，需要注意的是，大多数情况下你并不需要一开始就使用ruby-prof，你可以先从web server log， rails log或者是database log入手，如果确定了问题确实是由于你的rails代码引起的，那么ruby-prof就该登场亮相了。

无觅猜您也喜欢：

如何采访Ruby/Rails大牛

IBM DW Ruby on Rails资源中心上线

升级到Rails 3 Beta

theme_support: 为Rails应用添加theme支持

无觅

首先，由于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方法。

好了，到这里，这一系列的文章就结束了，附录中还有一些性能测试的数据和配置信息，就不一一列举了，感兴趣的可以下载原文查看。

无觅猜您也喜欢：

升级到Rails 3 Beta

Rails性能优化简明指南

Xapian，Sphinx在Rails中的性能比较

使用rails_reviewer优化Rails数据库查询性能

无觅

首先，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 ][ nclick ] = ”#{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[ nclick ] = ”#{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 , ffset ,
          :order , :select , :readonly, :group, :from )
end

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

VALID FIND OPTIONS = [
    :conditions , :include , :joins , :limit ,
    :offset , rder , :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）机制进行分析，并给出相应的优化策略。

无觅猜您也喜欢：

Rails性能优化简明指南

使用rails_reviewer优化Rails数据库查询性能

升级到Rails 3 Beta

Xapian，Sphinx在Rails中的性能比较

无觅

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识别，因此在数据库中缓存格式化后的字段可以大大减小字符处理的开销。

这一讲就先到这里，更多的优化技巧，请关注后续文章。

无觅猜您也喜欢：

Rails性能优化简明指南

升级到Rails 3 Beta

使用rails_reviewer优化Rails数据库查询性能

Xapian，Sphinx在Rails中的性能比较

无觅

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

• 不先进行性能测试就盲目的优化是非常愚蠢的
• 如果你的应用是因为设计不合理而导致性能低下，那么我建议你最好花点时间重构你的代码，而不是进行局部的优化，这只会使问题越来越多。
• 在优化之前，最好先为自己树立一个目标，这样可以防止因为过度优化而浪费时间，达到预期的目标后就该适可而止
• 没有必要对每一个页面都进行优化，只需要关注那些最经常被访问的页面就可以了，
• 在开发期间，进行持续的性能测量，这样有助于你在优化时定位性能瓶颈。

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

• 延迟，响应一个请求需要多少时间
• 吞吐量，每秒最多可以处理多少个请求
• 系统利用率，在大量请求需要处理的时候，你的系统在满负荷运转吗？
• 资源开销，在每个请求上所花费的开销

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

• Rails日志文件（debug_level >= Logger::DEBUG)
• Rails日志分析工具（需要将日志输出到syslog）
• Rails基准脚本（script/benchmarker）
• 数据库提供的性能分析器
• Apache Bench（ab或者ab2）
• httperf
• railsbench
  • 可在http://rubyforge.org/projects/railsbench/下载

我推荐Railsbench，它可以测量Rails处理一个请求的原始性能，关于Railsbench后面的文章会有介绍。
除了基准测试工具，你也可以选择单纯的性能测试工具：

• Ruby profiler
• Zen profiler
• rubyprof
• Rails profiler script
• Ruby Performance Validator（商业软件，仅支持windows）

不过事实上，Railsbench已经内置了性能测试工具，所以单独使用这些工具的必要性不大。
工具已经搞定，下面就让我们开始我们的优化之旅吧！

根据我的经验，Rails性能问题一般集中在以下几个方面：

• 很慢的helper方法
• 负责的路由
• 过多的联合（associations）
• 过多访问数据库
• 缓慢的session存取

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

这一讲就到这里，下一讲我们将针对以上几个问题给出具体的优化方案。

无觅猜您也喜欢：

Rails性能优化简明指南

升级到Rails 3 Beta

Rails应用性能优化2

使用rails_reviewer优化Rails数据库查询性能

无觅