आप अपने आवेदन को बहुप्रचारित कैसे करते हैं? क्या आप एसिंच फ़ंक्शन का उपयोग करते हैं? या आप एक नया धागा पैदा करते हैं? मुझे लगता है कि एसिंच फ़ंक्शन पहले से ही थ्रेड को फैल रहा है, इसलिए यदि आपका काम कुछ फ़ाइल पढ़ रहा है, आलसी होने और थ्रेड पर अपनी नौकरी को केवल स्पैनिश करने के लिए बस संसाधनों को "बर्बाद" कर देगा ... तो क्या कोई प्रकार का डिज़ाइन है धागे या asynch कार्यों का उपयोग कर?धागे या asynch?
स्पॉन्गिंग थ्रेड केवल संसाधनों को बर्बाद करने जा रहे हैं यदि आप उनमें से कई को शुरू करना शुरू करते हैं, तो एक या दो अतिरिक्त धागे प्लेटफॉर्म के असर को प्रभावित नहीं करेंगे, असर सिस्टम में वर्तमान में 70 से अधिक धागे हैं, और एमएसएन 32 का उपयोग कर रहा है (मुझे सच में पता नहीं है कि एक मैसेंजर कितने धागे का उपयोग कर सकता है, जब यह कम हो जाता है और वास्तव में कुछ भी नहीं कर रहा है ...)
एक थ्रेड को बढ़ाने के लिए एक अच्छा समय उपयोगी है जब कुछ समय लगेगा, लेकिन आपको कुछ और करने की ज़रूरत है।
उदाहरण के लिए एक गणना में 30 सेकंड लगेंगे। करने के लिए सबसे अच्छी बात गणना के लिए एक नया धागा है, ताकि आप स्क्रीन को अपडेट करना जारी रख सकें और किसी भी उपयोगकर्ता इनपुट को संभाल सकें क्योंकि यदि उपयोगकर्ता आपके ऐप को गणना करने के समाप्त होने तक फ्रीज करता है तो उपयोगकर्ता इससे नफरत करेंगे।
दूसरी ओर, कुछ ऐसा करने के लिए थ्रेड बनाना जो लगभग तुरंत किया जा सकता है, लगभग व्यर्थ है, क्योंकि बनाने के ऊपरी हिस्से (या यहां तक कि केवल थ्रेड पूल का उपयोग करके मौजूदा थ्रेड पर काम करना) केवल इतना करने से अधिक होगा पहली जगह में नौकरी।
कभी-कभी आप अपने ऐप को अपने अलग-अलग हिस्सों में विभाजित कर सकते हैं जो अपने धागे में चलते हैं। उदाहरण के लिए गेम में अपडेट/भौतिकी इत्यादि एक धागा हो सकता है, जबकि ग्रैपिक्स एक और हैं, ध्वनि/संगीत तीसरा है, और नेटवर्किंग एक और है। यहां समस्या यह है कि आपको वास्तव में यह सोचना होगा कि ये हिस्सों कैसे बातचीत करेंगे या अन्यथा आप बदतर हो सकते हैं, बग जो "यादृच्छिक रूप से" होती हैं, या यह भी डेडलॉक हो सकती है।
यदि आप .Net के बारे में बात कर रहे हैं, तो ThreadPool को न भूलें। थ्रेड पूल भी एसिंच फ़ंक्शन अक्सर उपयोग करता है। बहुत सारे धागे के लिए वास्तव में आपके प्रदर्शन को चोट पहुंचा सकता है। एक थ्रेड पूल को सबसे तेज़ काम करने के लिए पर्याप्त थ्रेड बनाने के लिए डिज़ाइन किया गया है। तो अपने धागे को फैलाने के बजाय थ्रेड पूल का उपयोग करें, जब तक कि थ्रेड पूल आपकी आवश्यकताओं को पूरा न करे।
पुनश्च: और एक आँख धागे के उपयोग आप जिस तरह से अपने आवेदन सूत्रण की जरूरत है और लंबे समय में यह आसान सुधार करने के लिए कर सकते हैं/अपने प्रदर्शन को नियंत्रित के बारे में अधिक सोचते हैं माइक्रोसॉफ्ट
से Parallel Extensions पर बाहर रखने।
Async विधियों का उपयोग करने के लिए तेज़ हैं लेकिन वे थोड़ा जादू हैं - बहुत सी चीजें उन्हें संभव बनाने के लिए होती हैं - इसलिए यह संभव है कि किसी बिंदु पर आपको कुछ ऐसा करने की आवश्यकता होगी जो वे आपको नहीं दे सकते। फिर आप कुछ कस्टम थ्रेडिंग कोड को आजमा सकते हैं और रोल कर सकते हैं।
यह सब आपकी आवश्यकताओं पर निर्भर करता है।
मैं हूँ दूसरा Fire Lancer's जवाब - अपने स्वयं के धागे बनाने एक शानदार तरीका बड़े कार्यों पर कार्रवाई करने के लिए या एक कार्य है कि अन्यथा तुल्यकालिक एप्लिकेशन के बाकी, करने के लिए "अवरुद्ध" हो लेकिन आप एक करना होगा संभालने के लिए है उस समस्या की स्पष्ट समझ जिसे आपको हल करना चाहिए और उस तरीके से विकसित करना चाहिए जो स्पष्ट रूप से धागे के कार्य को परिभाषित करता है, और जो भी करता है उसके दायरे को सीमित करता है।
उदाहरण के लिए मैंने हाल ही में काम किया - जावा कंसोल ऐप अनिवार्य रूप से स्क्रीन-स्क्रैपिंग यूआरएल द्वारा डेटा कैप्चर करने, डेटा को निकालने, डेटा निकालने और डेटाबेस में संग्रहीत करने के लिए समय-समय पर चलता है।
एक थ्रेडेड एप्लिकेशन के रूप में, जैसा कि आप उम्मीद करेंगे, एक उम्र ले ली है, एक 50kb पृष्ठ के लिए लगभग 1 यूआरएल औसत है। बहुत बुरा नहीं है, लेकिन जब आप बैच में हजारों यूआरएल को संसाधित करने की आवश्यकता के लिए बाहर निकलते हैं, तो यह अच्छा नहीं होता है।
ऐप प्रोफाइलिंग से पता चला है कि अधिकांश समय सक्रिय धागा निष्क्रिय था - यह आई/ओ ऑपरेशंस का इंतजार कर रहा था - रिमोट यूआरएल में सॉकेट खोलना, डेटाबेस से कनेक्शन खोलना आदि। यह इस तरह की स्थिति है जिसे मल्टीथ्रेडिंग के साथ आसानी से सुधार किया जा सकता है। बहु-थ्रेडेड होने के लिए पुनर्लेखन और एक के बजाय केवल 5 धागे के साथ, एक कोर सीपीयू पर भी, 20 गुना से अधिक थ्रूपुट में वृद्धि हुई।
इस उदाहरण में, प्रत्येक "कार्यकर्ता" धागा स्पष्ट रूप से सीमित था जो उसने किया - दूरस्थ रिमोट यूआरएल खोलें, डेटा को पार्स करें, इसे डीबी में स्टोर करें। सभी "उच्च स्तरीय" प्रसंस्करण - पार्स करने के लिए यूआरएल की सूची उत्पन्न करना, आगे काम करना, त्रुटियों को संभालना, सभी मुख्य धागे के नियंत्रण के साथ बने रहे।
उत्तर "यह निर्भर करता है"।
यह इस बात पर निर्भर करता है कि आप क्या हासिल करने की कोशिश कर रहे हैं। मुझे लगता है कि आप अधिक प्रदर्शन के लिए लक्ष्य कर रहे हैं।
सबसे आसान समाधान आपके प्रदर्शन को बेहतर बनाने के लिए एक और तरीका ढूंढना है। एक प्रोफाइलर चलाओ। गर्म धब्बे की तलाश करें। अनावश्यक आईओ को कम करें।
अगला समाधान आपके प्रोग्राम को कई प्रक्रियाओं में तोड़ना है, जिनमें से प्रत्येक अपने स्वयं के पता स्थान पर चला सकता है। यह सबसे आसान है क्योंकि व्यक्तिगत प्रक्रियाओं को एक-दूसरे को गड़बड़ करने का कोई मौका नहीं है।
अगला समाधान धागे का उपयोग करना है। इस बिंदु पर आप कीड़े का एक बड़ा हिस्सा खोल रहे हैं, इसलिए छोटे से शुरू करें, और केवल कोड के महत्वपूर्ण पथ को बहु-थ्रेड करें।
अगला समाधान asynch IO का उपयोग करना है। आम तौर पर केवल बहुत भारी लोड किए गए सर्वर को लिखने वाले लोगों के लिए अनुशंसा की जाती है, और फिर भी मैं उन मौजूदा ढांचे में से एक का फिर से उपयोग करना चाहूंगा जो विवरणों को दूर करते हैं। सी ++ फ्रेमवर्क आईसीई, या जावा के तहत एक ईजेबी सर्वर।
ध्यान दें कि इनमें से प्रत्येक समाधान में कई उप-समाधान हैं - थ्रेड और विभिन्न प्रकार के एसिंच आईओ की अलग-अलग नस्लों हैं, प्रत्येक में थोड़ा अलग प्रदर्शन विशेषताओं के साथ, लेकिन फिर भी, फ्रेमवर्क को आपके लिए इसे संभालने के लिए सबसे अच्छा है ।