优化GC
了解了如何通过优化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中添加如下语句:
# excerpt from dispatch. Fcgi
RailsFCGIHandler.process! nil, 50
这句话将禁止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方法,完全没有必要在每次处理请求时都进行解析,比如:
<%= end_form_tag %> ===> </form>
这纯粹就是浪费时间,还有我们前面提到的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)
了解了如何通过优化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中添加如下语句:
# excerpt from dispatch. Fcgi
RailsFCGIHandler.process! nil, 50
这句话将禁止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方法,完全没有必要在每次处理请求时都进行解析,比如:
<%= end_form_tag %> ===> </form>
这纯粹就是浪费时间,还有我们前面提到的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)