Rails应用优化指南

　　了解了如何通过优化Ruby代码来提升我们的Rails应用性能，现在让我们更深入一些，来看看Ruby的内存管理和垃圾回收机制。

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

• Ruby的内存管理策略是尽量减少内存占用;
• 标记和清除算法十分简单;
• 使用malloc来分配连续的内存块(Ruby heap);
• 复杂的数据结构;
• C扩展十分容易编写，但是当前的C接口很难实现generational GC(关于generational GC请参看[4])。

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

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

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

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

• 堆变的过大
• 小页面的性能受损
• 如果运行GC之后仍然没有足够的内存，Ruby还是会释放堆上的block

　　除了控制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方法，完全没有必要在每次处理请求时都进行解析，比如：

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

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

• 展开所有helper方法
• 去除不会调用到的代码
• 去除不会用到的变量(以及partials)
• 合并hash
• 替换常量
• 替换结果已确定的方法调用
• 替换符号

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

　　参考：

　　[1] https://railsexpress.de/blog/files/slides/railsconf2006.pdf

　　[2] http://railsexpress.de/blog/articles/2006/05/29/simpler-piggy-backing

　　[3] http://www.letrails.cn/archives/18

　　[4] http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)