मुझे डर है कि मैं यहां "गलत काम कर रहा हूं", अगर ऐसा है तो मुझे हटा दें और मैं माफी मांगता हूं। विशेष रूप से, मैं यह देखने में विफल रहता हूं कि मैं कुछ लोगों द्वारा बनाए गए स्वच्छ छोटे एनोटेशन कैसे बनाऊं। हालाँकि, इस धागे को बनाने के लिए मेरे पास कई चिंताएं / अवलोकन हैं।
1) लोकप्रिय जवाबों में से एक में छद्म कोड में टिप्पणी वाला तत्व
result = query( "select smurfs from some_mushroom" );
// twiddle fingers
go_do_something_with_result( result );
अनिवार्य रूप से फर्जी है। यदि थ्रेड कंप्यूटिंग कर रहा है, तो यह अंगूठे को मोड़ नहीं रहा है, यह आवश्यक काम कर रहा है। यदि, दूसरी ओर, यह केवल IO के पूरा होने की प्रतीक्षा कर रहा है, तो यह नहीं है CPU समय का उपयोग कर रहा है, कर्नेल में थ्रेड कंट्रोल इन्फ्रास्ट्रक्चर का पूरा बिंदु यह है कि सीपीयू को कुछ उपयोगी मिलेगा। यहाँ सुझाव दिया गया है कि "अपने अंगूठे को मोड़ने" का एकमात्र तरीका एक मतदान लूप बनाना होगा, और जिसने किसी वास्तविक वेबसर्वर को कोड नहीं किया है वह ऐसा करने के लिए पर्याप्त अयोग्य है।
2) "थ्रेड्स हार्ड हैं", केवल डेटा शेयरिंग के संदर्भ में समझ में आता है। यदि आपके पास अनिवार्य रूप से स्वतंत्र धागे हैं जैसे कि स्वतंत्र वेब अनुरोधों को संभालते समय मामला है, तो थ्रेडिंग तुच्छ सरल है, आप बस एक काम को संभालने के रैखिक प्रवाह को कोड करते हैं, और यह जानते हुए बैठते हैं कि यह कई अनुरोधों को संभाल लेगा, और प्रत्येक प्रभावी रूप से स्वतंत्र होगा। व्यक्तिगत रूप से, मैं उद्यम करूंगा कि अधिकांश प्रोग्रामर के लिए, क्लोजर / कॉलबैक मैकेनिज्म सीखना केवल टॉप टू बॉटम थ्रेड वर्जन को कोड करने की तुलना में अधिक जटिल है। (लेकिन हां, अगर आपको थ्रेड्स के बीच संवाद करना है, तो जीवन वास्तव में बहुत तेजी से कठिन हो जाता है, लेकिन फिर मैं इस बात से सहमत नहीं हूं कि क्लोजर / कॉलबैक तंत्र वास्तव में बदल जाता है, यह सिर्फ आपके विकल्पों को प्रतिबंधित करता है, क्योंकि यह दृष्टिकोण थ्रेड्स के साथ अभी भी प्राप्त करने योग्य है , वैसे भी, '
3) अब तक, किसी ने भी कोई वास्तविक सबूत प्रस्तुत नहीं किया है कि एक विशेष प्रकार का संदर्भ स्विच किसी अन्य प्रकार की तुलना में अधिक या कम समय लेने वाला क्यों होगा। मल्टी-टास्किंग कर्नेल बनाने में मेरा अनुभव (एम्बेडेड नियंत्रकों के लिए एक छोटे पैमाने पर, "वास्तविक" ओएस के रूप में इतना फैंसी कुछ भी नहीं है) सुझाव देता है कि यह मामला नहीं होगा।
4) उन सभी दृष्टांतों को जो मैंने उस तिथि को दर्शाने के लिए देखे हैं कि अन्य वेबसर्वरों की तुलना में नोड कितना तेज है, बुरी तरह से त्रुटिपूर्ण हैं, हालांकि, वे एक तरह से दोषपूर्ण हैं जो अप्रत्यक्ष रूप से एक लाभ का वर्णन करता है जिसे मैं निश्चित रूप से नोड के लिए स्वीकार करूंगा (और यह नगण्य है)। नोड की ज़रूरत नहीं लगती (न ही अनुमति भी, वास्तव में) ट्यूनिंग। यदि आपके पास एक थ्रेडेड मॉडल है, तो आपको अपेक्षित लोड को संभालने के लिए पर्याप्त थ्रेड्स बनाने की आवश्यकता है। इसे बुरी तरह से करें, और आप खराब प्रदर्शन के साथ समाप्त करेंगे। यदि बहुत कम धागे हैं, तो सीपीयू निष्क्रिय है, लेकिन अधिक अनुरोधों को स्वीकार करने में असमर्थ है, बहुत सारे थ्रेड्स बनाएं, और आप कर्नेल मेमोरी को बर्बाद कर देंगे, और जावा वातावरण के मामले में, आप मुख्य हीप मेमोरी को बर्बाद कर देंगे । अब, जावा के लिए, हीप को बर्बाद करना सिस्टम के प्रदर्शन को खराब करने का पहला, सबसे अच्छा तरीका है, क्योंकि कुशल कचरा संग्रह (वर्तमान में, यह जी 1 के साथ बदल सकता है, लेकिन ऐसा लगता है कि जूरी अभी भी उस बिंदु पर बाहर है क्योंकि 2013 की शुरुआत में कम से कम) बहुत सारे अतिरिक्त ढेर होने पर निर्भर करता है। तो, यह मुद्दा है, इसे कुछ थ्रेड्स के साथ ट्यून करें, आपके पास बेकार सीपीयू और खराब थ्रूपुट है, इसे बहुत सारे के साथ ट्यून करें, और यह अन्य तरीकों से बोगी करता है।
5) एक और तरीका है जिसमें मैं इस दावे के तर्क को स्वीकार करता हूं कि नोड का दृष्टिकोण "डिजाइन द्वारा तेज है", और यही वह है। अधिकांश थ्रेड मॉडल एक टाइम-स्लाइस किए गए संदर्भ स्विच मॉडल का उपयोग करते हैं, जो कि अधिक उपयुक्त (मूल्य निर्णय चेतावनी :) और अधिक कुशल (मूल्य निर्णय नहीं) प्रीमेप्टिव मॉडल के शीर्ष पर स्तरित होता है। यह दो कारणों से होता है, पहला, अधिकांश प्रोग्रामर को प्राथमिकता के बारे में समझ में नहीं आता है, और दूसरा, अगर आप विंडोज़ के वातावरण में थ्रेडिंग सीखते हैं, तो यह सवाल उठता है कि क्या आपको यह पसंद है या नहीं (बेशक, यह पहले बिंदु को पुष्ट करता है , विशेष रूप से, जावा के पहले संस्करणों ने सोलारिस कार्यान्वयन और विंडोज में गुणा करने पर प्राथमिकता से पूर्व उपयोग किया था। क्योंकि अधिकांश प्रोग्रामर समझ नहीं पाए और शिकायत की कि "थ्रेडिंग सोलारिस में काम नहीं करता है"। उन्होंने हर जगह मॉडल को बदल दिया)। वैसे भी, लब्बोलुआब यह है कि गुणा करना अतिरिक्त (और संभावित अनावश्यक) संदर्भ स्विच बनाता है। प्रत्येक संदर्भ स्विच सीपीयू समय लेता है, और उस समय को उस कार्य से प्रभावी रूप से हटा दिया जाता है जिसे वास्तविक नौकरी पर हाथ में लिया जा सकता है। हालाँकि, समय-समय पर परिसमापन के कारण निवेश की मात्रा समग्र समय के बहुत छोटे प्रतिशत से अधिक नहीं होनी चाहिए, जब तक कि कुछ बहुत बड़ा नहीं हो रहा है, और ऐसा कोई कारण नहीं है कि मैं उम्मीद कर सकूं कि मामला कुछ ही समय में हो सकता है। सरल वेबसर्वर)। तो, हाँ, गुणा करने में शामिल अतिरिक्त संदर्भ स्विच अक्षम हैं (और ये नहीं होते हैं और उस समय को उस कार्य से प्रभावी रूप से हटा दिया जाता है जिसे वास्तविक नौकरी पर किया जा सकता है। हालाँकि, समय-समय पर संदर्भ स्विचिंग के कारण निवेश किया गया समय समग्र समय के बहुत छोटे प्रतिशत से अधिक नहीं होना चाहिए, जब तक कि कुछ बहुत सुंदर नहीं हो रहा हो, और ऐसा कोई कारण नहीं है कि मैं यह उम्मीद कर सकूं कि कुछ ही समय में सरल वेबसर्वर)। तो, हाँ, टाइमिंग में शामिल अतिरिक्त संदर्भ स्विच अक्षम हैं (और ये नहीं होते हैं और उस समय को उस कार्य से प्रभावी रूप से हटा दिया जाता है जिसे वास्तविक नौकरी पर किया जा सकता है। हालाँकि, समय-समय पर संदर्भ स्विचिंग के कारण निवेश किया गया समय समग्र समय के बहुत छोटे प्रतिशत से अधिक नहीं होना चाहिए, जब तक कि कुछ बहुत सुंदर नहीं हो रहा हो, और ऐसा कोई कारण नहीं है कि मैं यह उम्मीद कर सकूं कि कुछ ही समय में सरल वेबसर्वर)। तो, हाँ, टाइमिंग में शामिल अतिरिक्त संदर्भ स्विच अक्षम हैं (और ये नहीं होते हैंएक नियम के रूप में कर्नेल थ्रेड्स, btw) लेकिन अंतर कुछ प्रतिशत थ्रूपुट का होगा, न कि उस तरह के पूरे नंबर के कारक जो प्रदर्शन के दावों में निहित होते हैं जो अक्सर नोड के लिए निहित होते हैं।
वैसे भी, उस सब के लिए क्षमा याचना लंबे समय से और तेजतर्रार है, लेकिन मुझे वास्तव में लगता है कि अब तक, चर्चा कुछ भी साबित नहीं हुई है, और मुझे इन स्थितियों में से किसी में सुनकर खुशी होगी:
a) नोड क्यों बेहतर होना चाहिए इसकी एक वास्तविक व्याख्या (ऊपर जिन दो परिदृश्यों के ऊपर मैंने उल्लिखित किया है, उनमें से पहला (खराब ट्यूनिंग) मेरा मानना है कि मैंने अब तक देखे गए सभी परीक्षणों के लिए वास्तविक स्पष्टीकरण दिया है। ([संपादित करें) ], वास्तव में, जितना अधिक मैं इसके बारे में सोचता हूं, अगर मैं सोच रहा हूं कि बड़ी संख्या में ढेर द्वारा उपयोग की जाने वाली मेमोरी यहां महत्वपूर्ण हो सकती है। आधुनिक थ्रेड्स के लिए डिफ़ॉल्ट स्टैक का आकार बहुत बड़ा है, लेकिन स्मृति द्वारा आवंटित किया गया है। क्लोजर-आधारित ईवेंट सिस्टम केवल वही होगा जो आवश्यक है)
ख) एक वास्तविक बेंचमार्क जो वास्तव में पसंद के थ्रेडेड सर्वर को उचित मौका देता है। कम से कम इस तरह, मुझे यह विश्वास करना बंद करना होगा कि दावे अनिवार्य रूप से झूठे हैं;> ([संपादित करें] जो संभवतः मेरे इरादे से अधिक मजबूत है, लेकिन मुझे लगता है कि प्रदर्शन लाभ के लिए दिए गए स्पष्टीकरण सबसे अच्छे हैं, और बिल्कुल भी अधूरे हैं दिखाए गए बेंचमार्क अनुचित हैं)।
चीयर्स, टोबी
select()थ्रेड संदर्भ स्वैप की तुलना में तेज है।