CentOS RoR应用性能优化的实战经验

核心提示： Rails应用程序优化包括ruby解析器的优化，缓存的使用，CentOS RoR应用性能优化的实战经验(2)，以及应用代码级别的优化，Stefans Kaes曾经在Railsconf 2006有一个Rails应用程序优化的演讲， JavaEye网站在CentOS RoR性能方面的经验就全部分享给大家了，也希望做C

Rails应用程序优化包括ruby解析器的优化，缓存的使用，以及应用代码级别的优化。Stefans Kaes曾经在Railsconf 2006有一个Rails应用程序优化的演讲，他的演讲PPT是极好的Rails性能优化指南，可以在这里下载:http://www.javaeye.com/topic/24508。他还编写了一个用于Rails性能测试的软件包RailsBench，大家可以参考。由于Stefans Kaes的代码优化文档已经写的非常详细了，因此我就不在一一复述，只提出几点对性能影响比较大的方面：

一、ruby解析器的优化

ruby的解析器性能是很糟糕的，ruby早期的主要用途是取代perl写批量处理的脚本的，并不是为服务器应用编写的，因此在内存分配策略上非 常不适合服务器应用。Stefans Kaes编写了一个ruby GC的补丁文件，在railsbench下载包里面提供了。虽然当前Railsbench提供的GC补丁只有针对ruby 1.8.4和1.8.5版本的，但是在ruby 18,6上面使用1.8.5的GC补丁也完全没有问题。GC补丁的作用主要是针对Rails应用开大了ruby的内存堆，可以有效提高内存堆的利用率，降 低GC的频率。根据Stefans Kaes提供的测试数据，打补丁并且调整参数以后，GC的频率下降到只有原来的1/10还不到。降低GC频率尽管并不能够提高单个请求的执行速度，但是可 以增加整体应用的负载能力。

我们在JavaEye的服务器上也使用了GC补丁，并且根据推荐参数进行了调整。在使用GC补丁之后，Web服务器的CPU负载下降了大概15% 左右，效果非常显著。当然开大内存堆的代价就是ruby进程会多消耗内存，在我们的服务器上，ruby打补丁之后多消耗了50%左右的物理内存。

二、缓存的使用

1、对象缓存

JavaEye上面关于对象缓存的讨论很多，我们也提供了JavaEye这方面很多数据，因此不展开了。CentOS RoR可以使用两个对象缓存，一个是 CachedModel，类似Hibernate，比较简单，对Model的CRUD操作自动进行缓存；另外一个是cache_fu，需要自己编码来添加 对象缓存，但提供了更多高级机制，目前我们使用的是cache_fu。在使用对象缓存的情况下，应该把查询方法的:include去掉，避免关联查询无法 利用缓存的现象。

2、查询缓存

对于统计类耗时查询，如果不要求实时性，那么可以使用memcache-client将查询结果缓存到memcached里面，例如博客排行榜之类。

3、页面局部缓存

对象缓存和查询缓存都是降低数据库访问负载的，但如果CentOS RoR的负载很高，那么只能依靠页面局部缓存了。传统的互联网web1.0网站很流行采用动 态页面静态化技术来提高网站的负载，但是对于web2.0网站来说，每个页面都带有登陆用户的个人信息，页面的很多部分需要实时更新，例如投票，点击统 计，digg，显示用户在线状态等等，动态页面静态化非常困难。当然如果你非要采用动态页面静态化，技术上也不是实现不了，可以通过AJAX请求来处理静 态页面的动态部分，但是这种解决方案的开发成本过高，而且性能未必会有明显的改善，大家看看新浪和搜狐博客就知道这种技术被应用的有多糟糕了。

web2.0网站比较常用使用页面局部缓存，一种情况是页面不需要实时更新的，那么只需要设置一个合理的过期时间就行了，这种情况我们目前使用的 比较多；另外一种情况是虽然不需要实时更新，但是会在用户执行某些操作后需要缓存过期，比方说博客个人主页的很多页面，这种情况下缓存过期策略会比较复 杂，考虑到合理的开发成本，我们尚未对这样的页面使用局部缓存。

此外，Rails的页面局部缓存有一个缺点，就是和页面查询结果对应的Action当中的查询语句要放在View里面，否则每次action里面的查询还是会被执行，但是这样做会破坏程序代码良好的MVC结构。这种情况下，也可以采用另外一个Cache插件: better rails caching，在缓存页面的同时可以缓存Action当中的查询语句。

三、应用代码的优化

Stefans Kaes的文档里面对应用代码的优化进行了非常详细的介绍，因此我这里只提两个比较重要的注意事项：

1、link_to

Rails的link_to是非常慢的，它的代码实现过于复杂，特别是Rails1.2引入了REST以后，大量的命名路由被使用，这些命名路由 还需要通过一次method_missing，那就更加缓慢了。因此对于被频繁使用的内部URL地址，一定要自己用字符串拼接方式改写，可以很明显提高 View的render性能。此外类似的helper还有很多，例如button_tag，image_tag啥啥的，如非必要，尽量不用他的 helper

2、正则表达式

ruby的正则表达式也是极慢，例如auto_fix这个helper的正则表达式就比较复杂，造成的结果就是一但大量使用 auto_fix，View的render就明显变慢，类似依赖正则表达式进行字符串过滤的helper有很多，如果需要频繁大量使用，请先自行做 benchmark。

Rails应用程序的内存泄漏问题和解决

内存泄漏是服务器端程序经常遇到的，有时候内存泄漏问题会让人很头疼，总体来说，Rails的内存泄漏问题比Java要少得多，这是因为Java内存泄漏最常见的三种情况在Rails当中不存在：

1、HttpSession导致的内存泄漏

Java程序员喜欢往session里面丢很多东西，最糟糕的是竟然有很多框架软件也肆无忌惮往session里面丢状态数据，但Rails的session是不放在内存里面的，所以无此烦恼。

2、数据库连接释放不彻底

Java的数据库连接池释放不彻底，以及查询游标释放不彻底，都必然导致内存泄漏。Rails没有数据库连接池，而是每个进程持有一个长连接，因此不存在这个问题，而且由于持有长连接，也不存在Java里面的OpenSessionInView的烦恼。

3、用静态变量持有全局共享数据

Java程序员很喜欢通过静态全局变量来持有共享数据，但共享数据忘记清理的话，也很容易导致内存泄漏，Ruby是SNA架构，多进程服务器模式，进程间无法共享数据，反而避免了全局共享数据带来的麻烦。

但是Rails应用有一种情况：在Ruby代码中调用C写的第三方ruby类库的时候，很容易导致内存泄漏，但这种内存泄漏反而在Java中极其 罕见。Ruby本身有GC来管理内存堆，但是代码一旦调用C写的第三方ruby类库，内存堆的分配权就掌握在第三方C库的实现上面了，如果这个C库的代码 质量不够好，内存泄漏就不可避免。由于ruby本身性能很差，因此计算量大的功能往往依赖底层的C库来实现，这下内存泄漏的潘多拉魔盒就打开了！而 Java性能比较好，功能都是纯Java编写，基本上看不到需要依赖第三方C库的情况，因此比较安全。

JavaEye也面临着内存泄漏的困扰，这方面困扰主要来自于Rmagic。Rmagick调用ImageMagick的C库来完成图片的操作， 从我们的监测来看，RMagick大多数情况下会缓慢的泄漏内存，在某些特定的图片操作上会急剧的泄漏内存。解决办法就是用mini_magick替代 Rmagick，mini_magick是直接调用ImageMagick的mogrify命令，另起一个进程来操作图片，操作完进程就结束了，绝无后 患，由于Linux的fork进程开销不大，因此也不必担心性能问题。

此外，调用第三方C库的ruby代码编写都需要高度小心，比方说JavaEye使用ferret实现全文检索，根据应用的需要调用ferret的 API来编写自己的analyzer，其中在实现token_stream方法上面使用了XXXAnalyzer.new和 XXXToken.new，XXXFilter.new，结果内存急剧泄漏，经过检查发现是Analyzer对象不能被反复创建，改成创建后缓存该对象就 好了，但是Filter和Token对象却必须每次创建，此外ferret的PerAnalyzerFilter也有内存泄漏问题。由于类库是用C编写 的，单纯看API文档或者看源代码片断一般无法判断出里面的内存泄漏陷阱的。

当遇到了难以解决和定位的内存泄漏问题，Ruby也有类似Java的内存Profiler工具：

1、Memory Profiler

一个纯ruby编写的内存探测器，原理很简单，就是用ruby的对象引用计数器ObjectSpace.each_object去遍历内存堆中的 每个ruby对象，进行统计和分析。用起来很简单，非常适合于开发环境下侦测内存泄漏问题，但不能用在生产环境下，极度影响Rails性能。

2、Bleak_house

Bleak_house给Ruby解析器打了补丁，插入相关的指令，可以从底层探测整个ruby内存堆中对象的情况，然后你可以定期dump出来 完整的内存堆里面的所有对象，再用bleak工具去分析dump文件，他比上面的工具分析的信息要全面，可以在测试环境和预发布环境下使用，但在生产环境 下，也会对应用的性能产生很大的影响，要慎用。

JavaEye网站在CentOS RoR性能方面的经验就全部分享给大家了，也希望做CentOS RoR的朋友都拿出来自己的经验和大家分享，共同学习和促进CentOS RoR的应用和普及。