在JRuby on Rails上构建Oracle Mix的收获

Oracle实验室最近发布了Oracle Mix，这是一个基于JRuby on Rails的社会网络应用。Rich Manalang刚刚在博客上分享了他在这个项目中的经验。虽然这个项目目前运行在JRuby上，但是最原始的工作却是用MRI完成的：

我们用标准的Ruby解释器（也就是MRI——Matz's Ruby Interpreter）和Ruby-OCI在Oracle DB XE上完成了Mix的大部分工作。用MRI来开发Rails应用还是要容易很多，因为JRuby的启动要花一段时间。

随后人们便发现Rails插件系统在帮助Mix与Oracle内部系统——这里指的是单点登录（SSO）策略——协同工作方面起到了很大作用：

这个项目至关重要的一点就是要支持Oracle单点登录策略。也就是说我们所部署的每一个Web应用都要通过Oracle SSO服务来支持单点登陆。我着实用了几天才找出解决方案，但方案一旦成型，把它插入到我们正在使用的acts_as_authenticated Rails插件中就并非难事了。

解决了这些问题后，开发团队在向JRuby on Rails进行部署时又遇到了新的难题——性能：

这一切都搞定以后，我们就开始在JRuby上做早期部署。性能简直烂得要死。单台应用服务器每秒只能处理20到40个请求。很明显，有些产品设置没有被配置好（比如，忘了对ruby类进行缓存等等）。我修改了一些环境设置后（标准的rails产品设置），单台应用服务器达到了每秒80个请求……情况好了一些，但是还远远不够。

长话短说，经过对性能问题的一阵调查研究以后，性能开始有所改善：

Ola和jRuby团队在jRuby代码中发现了一些有趣的瓶颈。一两天内，Ola和团队就做好了一个补丁，其后请求数达到了每秒150到200个。而应用服务器“热身（warm up）”以后，情况变得更好玩了……数值开始上升，达到了每秒钟400到600个请求。

这还仅仅是开始，因为按照作者所述，这些数字还是在没有进行任何缓存的服务器上得到的结果。那么是什么引起的性能提升呢？JRuby团队对一系列的问题进行了研究，并发现了一些老问题，诸如正则表达式的性能 ：

当我开始关注Rails中的正则表达式性能时，就发现了问题所在。每个请求中正好有50次正则表达式运算，于是我就写了个脚本，在MRI上检查每一次运算的性能。然后发现当拿MRI和JRuby相比较的时候，其中一次运算的性能显得相当怪异。实际上，它差不多要慢上200到1000倍。更糟的是，这性能还是非线性的。

这个问题实际上是在JRuby的each_line实现中出现的，和Rails代码无关。当这个问题和其它一些性能问题被一一发现并获得解决后，JRuby的速度有了显著的提升……

除了JRuby实现上的瓶颈，其他一些原因同样可以导致JRuby应用的速度变慢。Nick Siger指出了JRuby用户可以用一些小窍门来提升应用的速度。其中最重要的步骤是：

• 关掉ObjectSpace.
  ObjectSpace是一个可以允许用户遍历堆中所有对象的特性。很少有代码库真的会用到这个特性，所以关掉它并不会有什么相关的后果。实际上，JRuby 1.1默认就是把它关掉的。这个做法对性能的提升是很有效的：因为如果要提供ObjectSpace功能的话，每一个被创建的对象就都必须要在一个单独的列表结构中进行注册，从而增加了对象创建的代价。
• 确保使用了"server" VM
  可以通过一个简单的命令开关来使用“server” VM，从而获得更强劲的性能优化。
• 等待JVM热身
  这并不是真正的优化，但是能够保证测量出的性能数字是正确的。JVM工作的方式是，首先解析字节码，然后通过动态编译器来逐步将字节码进行优化并编译成native代码。只有实际上频繁用到的代码才会被编译和优化，而这个过程是需要一定时间的。这也就是说，在一个刚刚启动的JVM上测量每秒请求之类的性能，其结果要比在运行了一段时间的JVM上测量出来的性能差很多。
• 从稳定版本的JRuby（例如JRuby 1.0.x）切换到开发版本
  这对于JRuby1.1（当前的开发版本）而言效果尤其显著，因为它是第一个使用了完整的JIT的JRuby版本。但是，因为开发版可能会变动很大，所以使用最新版本也就意味着可能会引入新的、未被报告的bug。这些都会以不可预知的方式给应用程序造成破坏。当然，使用一个适当的test suite可以帮助开发人员将使用开发版带来的风险降低。跟上JRuby的开发步伐是有一定代价的，这个代价与所带来的性能提升相比孰轻孰重，还是要依据情况来判断。

查看英文原文： Lessons from building Oracle Mix on JRuby on Rails