2011-05-30 11 views
5

हालांकि नोड.जेएस बहुत गर्म विषय है, मुझे लगता है कि यह पता चला है कि यह पता चला है कि नोड.जेएस अपने कचरा संग्रह मॉडल (http://amix.dk/blog/post/) के कारण रीयल-टाइम एप्लिकेशन के लिए उपयुक्त नहीं हो सकता है 19,577)। और, कुछ बेंचमार्क से पता चलता है कि नोड.जेएस रिंगोजेएस (http://hns.github.com/2010/09/29/benchmark2.html) की तुलना में धीमी प्रतिक्रिया देता है।क्या उच्च लोड के तहत कचरा संग्रह के कारण नोड.जेएस स्केलेबिलिटी पीड़ित है?

उस समय के लिए, नोड.जेएस वी 8 जावास्क्रिप्ट इंजन से जुड़ा हुआ है जो पीढ़ी के स्टॉप-द-वर्ल्ड जीसी का उपयोग करता है।

तो, आने वाले अनुरोध बड़े होने पर नोड.जेएस को बर्बाद कर दिया जाएगा? यदि वास्तविक उत्पादन आंकड़े हैं, तो यह बेहतर होगा।

धन्यवाद

+0

यदि आपके पास पर्याप्त कनेक्शन हैं जो जीसी एक फर्क पड़ता है तो आप अपने कोर में स्केलिंग के कई प्रक्रियाओं के रूप में नोड चलाएंगे। यह कम से कम जीसी के "नुकसान" को कम करेगा। – Raynos

+1

यह अधिक थ्रूपुट ला सकता है, लेकिन जीसी में आने पर समय-समय पर उच्च विलंबता समस्या को कम नहीं करता है। –

उत्तर

2

कचरा संग्रहण की लागत ढेर में वस्तुओं की संख्या, विशेष रूप से लंबे समय तक रहा वस्तुओं की संख्या पर निर्भर करता है। आपके पास जितना अधिक होगा, जीसी में अधिक समय बिताया जाएगा।

हां, वी 8 वर्तमान में कुछ बड़े जीसी विराम ले सकता है यदि ढेर बड़ा होता है। ऐसा लगता है कि वी 8 टीम काम को फैलाने के द्वारा प्रत्येक जीसी विराम की लागत को कम करने पर काम कर रही है। आप --trace-gc के साथ इसे शुरू करके अपने स्वयं के नोड कार्यक्रमों में जीसी की लागत देख सकते हैं।

कई अनुप्रयोगों के लिए, जीसी की लागत तेजी से उत्कृष्ट अनुकूलन संकलक द्वारा ऑफ़सेट की जाती है। मैं एक साधारण कार्यक्रम की कोशिश करने और जी 8 की रिपोर्ट के अनुसार जीसी की लागत को मापने के साथ-साथ क्लाइंट विलंबता को क्लाइंट को मापने का सुझाव देना चाहता हूं। जब ग्राहक खुले इंटरनेट से कनेक्ट होते हैं तो मुझे जीसी लागत लगभग पूरी तरह से अनजान लगती है।

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