2012-04-20 17 views
18

मेरे पास एक रेल 3.2.2 एप्लिकेशन है जिसे मैं JRuby 1.6.7 (1.9.2 मोड) का उपयोग करके चलाने के लिए देख रहा हूं। पूरे 200 ठीक में 36ms:JRuby प्रदर्शन

मैं ~ 40ms एमआरआई रूबी 1.9.3 और एक ठेठ अनुरोध में चल रहे एक नमूना अनुप्रयोग में लौटने है (दृश्य: 27.5ms | ActiveRecord: 8.2ms)

JRuby का उपयोग कर के तहत पृष्ठ पर निर्भर करता है कि वही अनुरोध 3 से 20 गुना धीमा है। उपरोक्त के समान ऑपरेशन के लिए ~ 180ms: 180ms में 200 200 पूर्ण (दृश्य: 153.0ms | ActiveRecord: 24.0ms)

क्या यह सामान्य प्रदर्शन अंतर है? मैंने पढ़ा है कि एमआरआई के साथ जेआरबीई मोटे तौर पर गति पर बराबर है। परिणाम मेरे मैक और एक विंडोज सर्वर पर हैं (दुर्भाग्यवश इसे चलाने की आवश्यकता होगी)। टॉमकैट के तहत चल रहे वारबलर के साथ इसे पैकेज करना उतना ही धीमा है।

उपर्युक्त समय JRuby का परीक्षण करने के लिए बनाए गए मूल रेल ऐप से हैं। अधिक जटिल ऐप पर समय भी अलग-अलग होते हैं। उस ऐप पर कुछ पृष्ठों पर अधिक रूबी कोड चल रहा है। ऐसा लगता है कि जितना अधिक पृष्ठ रूबी निर्भर करता है उतना अधिक प्रदर्शन अंतर जो मैं देख रहा हूं। मैंने जरुबी का कोई ट्यूनिंग नहीं किया है, क्योंकि मुझे नहीं पता कि कहां से शुरू करना है।

तो मेरे प्रश्न हैं: क्या यह सामान्य है? JRuby ट्यून करने के लिए मैं क्या कर सकता हूँ?

उत्तर

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

नहीं, यह सामान्य नहीं है। एक बार जेवीएम गर्म हो जाने के बाद, कच्चे निष्पादन की गति और कचरा संग्रह के मामले में, जेआरबी के तहत रेल अनुरोध आमतौर पर एमआरआई के मुकाबले काफी अधिक प्रदर्शनशील होते हैं।

ऐसा लगता है कि आपके ऐप को गलत कॉन्फ़िगर किया गया है। जांच करने वाली पहली बात रेल की कॉन्फ़िगरेशन है - कृपया सुनिश्चित करें कि रेल विकास मोड में नहीं है, और config.threadsafe! आपके उत्पादन वातावरण में सक्षम है। थ्रेडसेफ मोड के परिणामस्वरूप आपका ऐप चलने पर स्मृति में लोड की गई रेल की केवल एक साझा प्रति होगी।

यह भी जांचें कि आपका डेटाबेस कॉन्फ़िगरेशन कनेक्शन पूलिंग का लाभ ले रहा है, उदा। database.yml में।

अंत में, अपनी जेवीएम और जेआरबीई सेटिंग्स की जांच करें - दोनों बेहद ट्यून करने योग्य हैं। आपको यह सुनिश्चित करने की ज़रूरत है कि स्टार्टअप पर JVM को आवंटित पर्याप्त मेमोरी है, और फिर आपके आवेदन के सामान्य सुचारू संचालन के लिए पर्याप्त मेमोरी है; अन्यथा JVM को लगातार समय-समय पर और अक्सर कचरा इकट्ठा करने के लिए मजबूर किया जाएगा, जो प्रदर्शन को काफी हद तक खराब कर देगा।

उदाहरण के लिए एक विनय specced VPS के लिए सेटिंग्स में से कुछ की तरह कुछ हो सकता है:

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

... लेकिन आँख बंद करके इन सेटिंग्स की प्रतिलिपि नहीं है! आपको अपने सर्वर पर उपलब्ध स्मृति संसाधनों के संबंध में आपके लिए अच्छा क्या प्रयोग करना होगा और काम करना होगा।

यह कहा गया है, जबकि जेआरबीआई एमआरआई के तहत कई रेल प्रक्रियाओं की कुल राशि की तुलना में कम स्मृति का उपभोग करेगा, आपको निश्चित रूप से एक एकल जेवीएम प्रक्रिया के लिए थोड़ा और आगे आवंटित करने की आवश्यकता होगी।JRuby के लिए उदार हो, और JRuby आप JRuby और यहाँ JVM ट्यूनिंग के बारे में अधिक पढ़ सकते हैं अपने दयालुता के लिए आपको पुरस्कृत करेगा :-)

: https://github.com/jruby/jruby/wiki/PerformanceTuning

अद्यतन

आप स्थापित करने की आवश्यकता नहीं है config.threadsafe!रेल्स 4.0 और ऊपर; यह डिफ़ॉल्ट रूप से थ्रेडसेफ है।

+0

विकास मोड की तुलना में 'उत्पादन' मोड में चलना, कभी-कभी 5-6 गुना तेज प्रतिक्रिया देता है। कम से कम मेरे मामले में था। उस पर ध्यान देने के लिए धन्यवाद। – Aleks

3

जावा 7 के साथ jruby 1.6.8 या jruby 1.7.x में अपग्रेड करें!

बहुत बढ़िया प्रदर्शन।

हमारे पास एक ही समस्या थी और अब यह बहुत तेज़ है (केवल संस्करणों को स्विच करने के साथ)।

+2

मेरे पास वही खराब प्रदर्शन है। जावा 7 और जर्बी 1.7 का प्रयास किया, एमआरआई के साथ एक मजबूत वर्तमान परियोजना की तुलना में एक ताजा रेल ऐप अधिक धीमी है। अर्ग। – m4tm4t

4

मैं वही व्यवहार देख रहा हूं, लेकिन ध्यान रखें कि जेआरबी को गर्म करने में काफी समय की आवश्यकता है। मैं वास्तव में थोड़ा आशावादी हूं कि अंततः जेआरबीई पकड़ लेगा।

कुछ विकल्प सेट करके इसे 'वार्मिंग अप' तेज करना संभव है। रूबी -> जावा बाईटकोड संकलक JIT करने के लिए सिखाया जा सकता है निम्नलिखित env वर की स्थापना करके पहले मंगलाचरण पर हर विधि संकलन: कई बार एक रेल पृष्ठ को ताज़ा करने के बाद,

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

मेरे लिए, यह अभी भी 2 है एमआरआई रूबी की तुलना में -3x धीमी है, लेकिन कम से कम 3x तेज है।

यह भी ध्यान रखें कि जावा रनटाइम जावा बाइटकोड को मशीन कोड में समान रूप से संकलित करता है, लेकिन यह जेआईटी तब तक नहीं लाएगा जब तक कोई विधि लागू नहीं होती है। सर्वर रनटाइम का उपयोग करते समय 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 ऑन रेल्स एमआरआई से समान या बेहतर प्रदर्शन के बारे में देता है।

कृपया ध्यान दें कि ये विकल्प केवल अप्रिय बेंचमार्किंग के लिए हैं! हकीकत में यह जेआईटी संकलन को आक्रामक रूप से चलाने के लिए लगभग हमेशा एक बुरा विचार है; आप कोड के जेआईटी-संकलन पर मूल्यवान समय और स्मृति बर्बाद कर रहे हैं जो केवल कुछ बार चलाया जा सकता है। हालांकि, यह दिखाता है कि प्रारंभिक रनों के आधार पर आप अपेक्षाकृत जेआरबी प्रदर्शन कैसे बेहतर हो सकते हैं।

मुझे बताएं कि यह आपके लिए काम करता है या नहीं।

संबंधित मुद्दे