這是別人的實驗結論，而且是用 JRuby 1.1。
一般人對於 Java 的效能都有「很慢」的印象，不過隨著 Java EE application 的成長，以及 Java Virtual Machine 不斷地改良，這個問題已經比較少被拿出來講了。最近 RoR 快速竄紅，scripting language 的效能又是開發者間茶餘飯後的話題。JRuby 的出現，更是讓很多人抱著懷疑的態度來看待它的效能問題。
所以，我們來看看這篇文章所作的實驗，它用了三種 configurations: MRI(也就是 native, C-implementation 的 ruby)/Mongrel、JRuby/Mongrel 及 JRuby/GlassFish(Sun 的 application server)。
從其文章兩張統計圖片（原始資料在這裡）可以看得出來。雖然在 requests 數目少的時候 MRI/Mongrel 輕鬆樂勝，但 request變多，執行夠久之後拉長來看，三者的效能幾乎差不了多少，而且有時候 JRuby 的表現還會稍微好一點，所以可以推斷出，JRuby 只要經過一點「暖身」（我想是跟一些 cache、JIT compliation有關）就可以發揮得很好了。
當然，JRuby 目前才在 1.0 ~ 1.1 的階段，未來成長的空間還很大，JRuby on Rails 的效能肯定是指日可待的。不過就筆者這兩天的實驗，SVN trunk 裡的 jruby 1.1 還不太能用在 Rails 1.2.5 上面(在 windows 下, rake 會爛在 file path 的地方)....這好像有點糟..
