जो मैं देखता हूं, उससे नोड में एक कार्यक्रम "लंबे समय" को भेजने के लिए लेता है, नोड किसी प्रकार की "घटनाओं की कतार" बनाता है, और जितनी जल्दी हो सके, वे एक-एक करके ट्रिगर होते हैं।कितने घटनाएँ node.js कतार कर सकते हैं?
यह कतार कितनी देर तक हो सकती है?
हालांकि यह एक साधारण सवाल की तरह प्रतीत हो सकता है, यह वास्तव में एक जटिल समस्या है; दुर्भाग्य से, कोई आसान संख्या नहीं है कि कोई आपको दे सकता है।
पहला: दीवार का समय वास्तव में यहां कुछ भी नहीं खेलता है। सभी घटनाएं एक ही फैशन में भेजी जाती हैं, चाहे चीजें "लंबे समय तक" ले रही हों या नहीं। दूसरे शब्दों में, सभी घटनाएं "कतार" से गुज़रती हैं।
दूसरा: कोई एकल कतार नहीं है। ऐसे कई स्थान हैं जहां जेएस में विभिन्न प्रकार की घटनाएं भेजी जा सकती हैं। (निम्नलिखित आप know what a tick is मान लिया गया है।)
process.nextTick() को पारित कर रहे हैं। अगली टिक कतार खाली होने तक उन्हें वर्तमान टिक के अंत में बुलाया जाता है।setImmediate() पर गुजरती हैं। उन्हें अगले टिक की शुरुआत में बुलाया जाता है। (यह है कि nextTick कार्य अनिश्चित काल के लिए वर्तमान टिक करने के लिए चीजों को जोड़ सकते हैं, क्या हो रहा है, जबकि setImmediate कार्य केवल अगले टिक के लिए कतार में बातें जोड़ सकते हैं से अन्य कार्यों को रोकने का मतलब है।)epoll के माध्यम से libuv द्वारा नियंत्रित किया जाता है/क्रमशः लिनक्स/मैक/विंडोज पर kqueue/आईओसीपी। जब ओएस libuv को सूचित करता है कि I/O हुआ है, तो बदले में यह जेएस में उपयुक्त हैंडलर को आमंत्रित करता है।इवेंट लूप का दिया गया टिक शून्य या अधिक I/O ईवेंट संसाधित कर सकता है; यदि टिक में लंबा समय लगता है, तो I/O ईवेंट ऑपरेटिंग सिस्टम कतार में कतारबद्ध होंगे।चूंकि ऐसे कई स्थान हैं जहां काम कतारबद्ध किया जा सकता है, it is not easy to answer "how many items are currently queued", उन कतारों की पूर्ण सीमा कितनी कम है। अनिवार्य रूप से, आपके कार्य कतारों के आकार की हार्ड सीमा रैम उपलब्ध है।
व्यवहार में, अपने अनुप्रयोग होगा:
... किसी भी कतार के आकार से पहले समस्याग्रस्त हो जाता है।
यदि आप रुचि रखते हैं कि आपका ऐप भारी भार के तहत है या नहीं, toobusy रुचि का हो सकता है - यह घटना के लूप के प्रत्येक टिक को निर्धारित करने के लिए होता है कि आपका ऐप असामान्य समय प्रसंस्करण कर रहा है या नहीं प्रत्येक टिक (जो इंगित कर सकती है कि आपकी कार्य पंक्तियां बहुत बड़ी हैं)।
एक विशिष्ट घटना के लिए हैंडलर को सिंक्रनाइज़ कहा जाता है (क्रम में उन्हें जोड़ा गया था) जैसे ही ईवेंट उत्सर्जित होता है, वे बिल्कुल देरी नहीं कर रहे हैं।
ईवेंट हैंडलर की कुल संख्या केवल v8 और/या उपलब्ध रैम की मात्रा से ही सीमित है।
संभाला जाता है यदि रैम सीमा तक पहुंच जाती है, तो अतिरिक्त मेमोरी को तब तक रोकना पड़ेगा जब तक कि अधिक मेमोरी मुक्त न हो जाए या वीएम को समाप्त कर दिया जाए? मैं यह समझने की कोशिश कर रहा हूं कि यह मेरी [ओओएम समस्या] का कारण है (http://stackoverflow.com/questions/36492268/nodejs-running-out-of-memory-processing-csv-files/36493158?noredirect= 1 # टिप्पणी 60612338_36493158) –
@DmitryB। यदि v8 किसी भी स्मृति को आवंटित नहीं कर सकता है और जीसी पर्याप्त प्रयास विफल रहता है, तो यह किसी अन्य कार्यक्रम की तरह ही मर जाएगा। – mscdex
मेरा मानना है कि आप उन परिचालनों के बारे में बात कर रहे हैं जो पूर्ण करने के लिए एक अनिश्चित समय ले सकते हैं, जैसे http अनुरोध या फाइल सिस्टम एक्सेस।
नोड आपको इस प्रकार के संचालन को असीमित रूप से पूरा करने का एक तरीका देता है, जिसका अर्थ है कि आप ऑपरेशन शुरू करने के लिए नोड, या तृतीय पक्ष लाइब्रेरी बता सकते हैं, और फिर आपको सूचित करने के लिए कुछ कोड (एक फ़ंक्शन जिसे आप परिभाषित करते हैं) को कॉल करते हैं जब ऑपरेशन पूरा हो जाता है। यह घटना श्रोताओं, या कॉलबैक कार्यों के माध्यम से किया जा सकता है, जिनमें से दोनों की अपनी सीमाएं हैं।
ईवेंट श्रोताओं के साथ आपके पास अधिकतम श्रोताओं की अधिकतम मात्रा आपके पर्यावरण के अधिकतम सरणी आकार पर निर्भर है। Node.js के मामले में जावास्क्रिप्ट इंजन v8 है, लेकिन this post के अनुसार ~ 4 बिलियन तत्वों के 5 वें ईसीएमए मानक द्वारा अधिकतम सेट किया गया है, जो एक सीमा है जिसे आपको कभी खत्म नहीं करना चाहिए।
कॉलबैक के साथ आपके पास सीमा अधिकतम कॉल स्टैक आकार है, जिसका अर्थ है कि आपके कार्य एक-दूसरे को कितने गहरे कॉल कर सकते हैं। उदाहरण के लिए आप एक कॉलबैक कॉल कर सकते हैं जिसे कॉलबैक कॉल करना कॉलबैक को कॉल करना है, कॉलबैक कॉल करना आदि। कॉल स्टैक साइज यह बताता है कि कॉलबैक कॉलबैक कैसे कॉल कर सकता है। ध्यान दें कि कॉल स्टैक आकार इवेंट श्रोताओं के साथ एक सीमा हो सकता है और साथ ही वे अनिवार्य रूप से कॉलबैक हैं जिन्हें कई बार निष्पादित किया जा सकता है।
और ये प्रत्येक के साथ सीमाएं हैं।
पुन घटना श्रोताओं, सरणी आकार श्रोता * कॉलबैक फ़ंक्शंस * घटनाओं के लिए सुनना, कतार धारण घटनाओं के आकार पर सीमा को प्रेषित करने की सीमा पर सीमा है। साथ ही, कॉल स्टैक सीमाओं को 'setImmediate' /' process.nextTick' के माध्यम से चारों ओर काम किया जा सकता है। – josh3736
जहां तक मुझे पता है, वहां भेजने की प्रतीक्षा की जाने वाली घटनाओं की कोई "कतार" नहीं है। जब 'प्रेषण' या 'emit' या इसी तरह के फ़ंक्शन को कॉल किया जाता है, तो उस ईवेंट के सभी श्रोताओं को 'प्रेषण' रिटर्न से पहले बुलाया जाता है। अनुमोदित है कि आप नेस्टेड इवेंट प्रेषण कर सकते हैं, जहां एक ईवेंट श्रोता एक और घटना भेज सकता है, लेकिन अभी भी कोई "क्यूइंग" चल रहा है। हालांकि यह घटनाओं के साथ मेरा अनुभव है। कुछ ऐसी व्यवस्था हो सकती है जो क्यूई का उपयोग करने वाले कॉल स्टैक को रीसेट करने के लिए नोड का उपयोग करता है? लेकिन मैंने इसका वर्णन कैसे किया है आम तौर पर घटनाएं कैसे काम करती हैं। – BAM5
इसके अलावा, हां, सरणी आकार सीमा एक ईवेंट प्रकार के लिए सुनने वाले श्रोताओं की संख्या पर सीमा है। – BAM5
मुझे नहीं लगता कि आपकी सीमा है लेकिन आपकी रैम है। – Bergi
मेरा मानना है कि घटनाएं वास्तव में हमेशा कतारबद्ध होती हैं। – jcaron
मुझे नहीं लगता कि इस तरह की कतार को –