Ubuntu ruby解析器应用程序的优化

想知道到Ubuntu ruby系统的真相么，想知道Ubuntu ruby系统中藏有的内在奥义么，只有我来给大家全面讲解介绍Ubuntu ruby系统Rails应用程序优化包括Ubuntu ruby解析器的优化，缓存的使用，以及应用代码级别的优化。Stefans Kaes曾经在Railsconf 2006有一个Rails应用程序优化的演讲，他的演讲是极好的Rails性能优化指南，可以在这里下载:http://www.javaeye.com/topic/24508。

Rails应用程序的优化

他还编写了一个用于Rails性能测试的软件包RailsBench，大家可以参考。由于Stefans Kaes的代码优化文档已经写的非常详细了，因此我就不在一一复述，只提出几点对性能影响比较大的方面：

一、Ubuntu ruby解析器的优化

Ubuntu ruby解析器性能是很糟糕的，Ubuntu ruby解析器早期的主要用途是取代perl写批量处理的脚本的，并不是为服务器应用编写的，因此在内存分配策略上非常不适合服务器应用。Stefans Kaes编写了一个Ubuntu ruby解析器 GC的补丁文件，在railsbench下载包里面提供了。

虽然当前Railsbench提供的GC补丁只有针对Ubuntu ruby解析器 1.8.4和1.8.5版本的，但是在Ubuntu ruby解析器 18,6上面使用1.8.5的GC补丁也完全没有问题。GC补丁的作用主要是针对Rails应用开大了Ubuntu ruby解析器的内存堆，可以有效提高内存堆的利用率，降低GC的频率。根据Stefans Kaes提供的测试数据，打补丁并且调整参数以后，GC的频率下降到只有原来的1/10还不到。降低GC频率尽管并不能够提高单个请求的执行速度，但是可以增加整体应用的负载能力。

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

二、缓存的使用

1、对象缓存

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

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

3、页面局部缓存
对象缓存和查询缓存都是降低数据库访问负载的，但如果RoR的负载很高，那么只能依靠页面局部缓存了。传统的互联网web1.0网站很流行采用动态页面静态化技术来提高网站的负载，但是对于web2.0网站来说，每个页面都带有登陆用户的个人信息，页面的很多部分需要实时更新.

例如投票，点击统计，digg，显示用户在线状态等等，动态页面静态化非常困难。当然如果你非要采用动态页面静态化，技术上也不是实现不了，可以通过AJAX请求来处理静态页面的动态部分，但是这种解决方案的开发成本过高，而且性能未必会有明显的改善，大家看看新浪和搜狐博客就知道这种技术被应用的有多糟糕了。

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

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

三、应用代码的优化

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