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 的开发步伐是有一定代价的,这个代价与所带来的性能提升相比孰轻孰重,还是要依据情况来判断。
评论