2012-04-20 28 views
18

我有一個Rails 3.2.2應用程序,我正在使用JRuby 1.6.7(1.9.2模式)運行。JRuby性能

我在MRI紅寶石1.9.3和一個典型的請求運行一個示例應用程序將返回在40毫秒〜: 完成200 OK在36ms:|:在JRuby中使用

(查看8.2ms 27.5ms的ActiveRecord)根據頁面的不同,相同的請求可能會慢3到20倍。與上面相同的操作需要〜180ms: 在180ms內完成200 OK(查看:153.0ms | ActiveRecord:24.0ms)

這是一個正常的性能差異嗎?我讀過JRuby與MRI的速度大致相當。結果在我的Mac和Windows服務器上(不幸的是它需要運行)。在Tomcat下運行的Warbler包裝起來也很慢。

上述時間來自爲測試JRuby而創建的基本rails應用程序。在更復雜的應用程序中,時間更加分開。在那個應用程序中,有些頁面上運行着更多的ruby代碼。看起來頁面越是依賴ruby,我觀察到的性能差異就越大。我沒有做過JRuby的調整,因爲我不知道從哪裏開始。

所以我的問題是:這是正常的嗎?我能做些什麼來調整JRuby?

回答

18
Is this a normal performance difference? 
I have read that JRuby is roughly equal on speed with MRI. 

不,這不正常。一旦JVM變暖,在原始執行速度和垃圾回收方面,JRuby下的Rails請求通常比MRI下性能更高。

這聽起來像你的應用程序配置錯誤。首先要檢查的是Rails本身的配置 - 請確保Rails不處於開發模式,並且config.threadsafe!已在您的生產環境中啓用。線程安全模式將導致只有一個Rails共享副本在應用程序運行時加載到內存中。

還要檢查您的數據庫配置是否利用連接池,例如, pool: 20 in database.yml

最後,檢查您的JVM和JRuby設置 - 兩者都是高度可調的。您需要確保在啓動時有足夠的內存分配給JVM,然後有足夠的內存用於應用程序的正常平滑操作;否則JVM將不斷被迫過早和經常垃圾收集,這將顯着降低性能。

例如一些對適度specced VPS的設置可能是這樣的:

-Xmx500m -Xss1024k -Djruby.memory.max=500m -Djruby.stack.max=1024k

... ...但不要盲目照搬這些設置!您將不得不試驗一下您的服務器上可用的內存資源,以確定對您有什麼好處。也就是說,儘管JRuby可能會消耗比MRI下多個Rails進程總和更少的內存,但您肯定需要爲單個JVM進程分配更多的前期內存。大方的JRuby和JRuby的將獎勵你的好意:-)

你可以閱讀更多有關調整JRuby和這裏的JVM:https://github.com/jruby/jruby/wiki/PerformanceTuning

更新

你並不需要設置config.threadsafe! in Rails 4.0及以上;它默認是線程安全的。

+0

在'生產'模式下運行,相比於開發模式,有時會帶來5-6倍的響應速度。至少這是我的情況。感謝您的注意。 – Aleks 2016-11-06 19:04:41

3

用JAVA 7升級到jruby 1.6.8或jruby 1.7.x!

令人敬畏的表現。

我們遇到了同樣的問題,現在速度非常快(只需切換版本)。

+2

我有同樣糟糕的表現。試過java 7&Jruby 1.7,新版Rails應用程序比使用MRI的強大當前項目更慢。爾格。 – m4tm4t 2013-01-13 23:51:04

4

我看到相同的行爲,但請記住JRuby需要更長的時間進行預熱。實際上我對JRuby最終會趕上來感到有點樂觀。

可以通過設置幾個選項來加快「預熱」。紅寶石 - > Java字節碼編譯器也可以教給JIT通過設置以下的環境變量編譯每個方法第一次調用:

export JRUBY_OPTS="-J-Djruby.jit.threshold=1 -J-Djruby.jit.max=16384"

對於我來說,刷新Rails的頁面了幾次後,它仍然是2比MRI紅寶石慢3倍,但至少比以前快3倍。

另外請記住,java運行庫是JIT以類似的方式將java字節碼編譯爲機器代碼,但這個JIT不會啓動,直到在使用服務器運行時調用10.000x的方法。這可以是configured as well

export JRUBY_OPTS="-J-Djruby.jit.threshold=10 -J-Djruby.jit.max=16384 -J-XX:CompileThreshold=10" -J-XX:ReservedCodeCacheSize=128M"

通過這些選項,JRuby的on Rails的提供了有關比MRI相同或更好的性能。

請注意,這些選項僅用於不耐煩的基準!實際上,積極運行JIT編譯幾乎總是一個糟糕的主意;你正在浪費寶貴的時間和內存來編譯可能只運行幾次的代碼。但是,它顯示了JRuby的最終性能可能比您預期的更好,這取決於初始運行。

讓我知道這是否適合你。