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的文档里面对应用代码的优化进行了非常详细的介绍,因此我这里只提两个比较重要的注意事项:

相关推荐