मेरे पास सभी उत्तर नहीं हैं। उम्मीद है कि मैं इस पर कुछ प्रकाश डाल सकता हूं ।
.NET के थ्रेडिंग मॉडल के बारे में मेरे पिछले बयानों को सरल बनाने के लिए, बस यह जान लें कि समानांतर लाइब्रेरी टास्क का उपयोग करती है, और टास्क के लिए डिफ़ॉल्ट टास्कसोल्डर, थ्रेडपूल का उपयोग करता है। उच्चतर आप पदानुक्रम में जाते हैं (थ्रेडपूल सबसे नीचे है), आइटम बनाते समय आपके पास जितना अधिक ओवरहेड होगा। यह अतिरिक्त ओवरहेड निश्चित रूप से इसका मतलब यह नहीं है कि यह धीमा है, लेकिन यह जानना अच्छा है कि यह वहां है। अंततः एक बहु-थ्रेडेड वातावरण में आपके एल्गोरिथ्म का प्रदर्शन इसके डिजाइन के लिए नीचे आता है। जो क्रमबद्ध रूप से अच्छा प्रदर्शन करता है वह समानांतर में भी अच्छा प्रदर्शन नहीं कर सकता है । आपको कठिन और तेज़ नियम देने के लिए बहुत सारे कारक शामिल हैं, वे इस बात पर निर्भर करते हैं कि आप क्या करने की कोशिश कर रहे हैं। जब से आप नेटवर्क अनुरोधों के साथ काम कर रहे हैं, मैं कोशिश करूँगा और एक छोटा सा उदाहरण दूंगा।
मुझे बताएं कि मैं सॉकेट्स का कोई विशेषज्ञ नहीं हूं, और मुझे ज़ेरोक-आइस के बारे में कुछ भी नहीं पता है। मुझे एसिंक्रोनस ऑपरेशन के बारे में कुछ पता नहीं है, और यह वह जगह है जहाँ यह वास्तव में आपकी मदद करेगा। यदि आप सॉकेट के माध्यम से एक तुल्यकालिक अनुरोध भेजते हैं, जब आप कॉल करते हैं Socket.Receive(), तो आपका धागा तब तक ब्लॉक होगा जब तक कि एक अनुरोध प्राप्त नहीं होता है। यह अच्छा नहीं है। आपका धागा अवरुद्ध होने के बाद कोई और अनुरोध नहीं कर सकता। सॉकेट का उपयोग करना। Beginxxxxxx (), I / O अनुरोध बनाया जाएगा और सॉकेट के लिए IRP कतार में रखा जाएगा, और आपका धागा चालू रहेगा। इसका मतलब है, कि आपका धागा वास्तव में बिना किसी अवरोध के लूप में हजारों अनुरोध कर सकता है!
यदि मैं आपको सही तरीके से समझ रहा हूं, तो आप अपने परीक्षण कोड में ज़ीरोक-आइस के माध्यम से कॉल का उपयोग कर रहे हैं, वास्तव में एक http समापन बिंदु तक पहुंचने की कोशिश नहीं कर रहे हैं। अगर ऐसा है, तो मैं स्वीकार कर सकता हूं कि मुझे नहीं पता कि ज़ीरोक-आइस कैसे काम करता है। हालाँकि, मैं यहाँ दी गई सलाह का पालन करने का सुझाव दूंगा , विशेषकर भाग Consider Asynchronous Method Invocation (AMI):। पेज यह दिखाता है:
एएमआई का उपयोग करके, ग्राहक नियंत्रण के धागे को फिर से भेजता है जैसे ही मंगलाचरण भेजा गया है (या, अगर इसे तुरंत नहीं भेजा जा सकता है, तो कतार लगाई गई है), ग्राहक को उस धागे का उपयोग करने की अनुमति देता है ताकि अन्य उपयोगी काम कर सकें। ।
जो मैंने .NET सॉकेट्स का उपयोग करके ऊपर वर्णित के बराबर प्रतीत होता है। बहुत सारे भेजने की कोशिश करने पर प्रदर्शन को बेहतर बनाने के अन्य तरीके हो सकते हैं, लेकिन मैं यहां या उस पृष्ठ पर सूचीबद्ध किसी अन्य सुझाव के साथ शुरू करूंगा। आप अपने आवेदन के डिजाइन के बारे में बहुत अस्पष्ट हैं, इसलिए मैं ऊपर दिए गए से अधिक विशिष्ट हो सकता हूं। बस याद रखें, जो कुछ भी आपको आवश्यक है उसे प्राप्त करने के लिए आवश्यक से अधिक थ्रेड्स का उपयोग न करें , अन्यथा आपको अपने एप्लिकेशन को आपके इच्छित से अधिक धीमी गति से चलने की संभावना मिलेगी।
स्यूडोकोड में कुछ उदाहरणों ने (जितना संभव हो उतना बर्फ के करीब बनाने की कोशिश की मेरे बिना वास्तव में इसे सीखना है):
var iterations = 100000;
for (int i = 0; i < iterations; i++)
{
// The thread blocks here waiting for the response.
// That slows down your loop and you're just wasting
// CPU cycles that could instead be sending/receiving more objects
MyObjectPrx obj = iceComm.stringToProxy("whateverissupposedtogohere");
obj.DoStuff();
}
एक बेहतर तरीका:
public interface MyObjectPrx : Ice.ObjectPrx
{
Ice.AsyncResult GetObject(int obj, Ice.AsyncCallback cb, object cookie);
// other functions
}
public static void Finished(Ice.AsyncResult result)
{
MyObjectPrx obj = (MyObjectPrx)result.GetProxy();
obj.DoStuff();
}
static void Main(string[] args)
{
// threaded code...
var iterations = 100000;
for (int i = 0; i < iterations; i++)
{
int num = //whatever
MyObjectPrx prx = //whatever
Ice.AsyncCallback cb = new Ice.AsyncCallback(Finished);
// This function immediately gets called, and the loop continues
// it doesn't wait for a response, it just continually sends out socket
// requests as fast as your CPU can handle them. The response from the
// server will be handled in the callback function when the request
// completes. Hopefully you can see how this is much faster when
// sending sockets. If your server does not use an Async model
// like this, however, it's quite possible that your server won't
// be able to handle the requests
prx.GetObject(num, cb, null);
}
}
ध्यान रखें कि अधिक धागे! = सॉकेट भेजने की कोशिश करते समय बेहतर प्रदर्शन (या वास्तव में कुछ भी करना)। थ्रेड्स जादू नहीं हैं कि वे अपने आप जो भी समस्या आप पर काम कर रहे हैं, को स्वचालित रूप से हल करेंगे। आदर्श रूप से, आप प्रति कोर 1 थ्रेड चाहते हैं, जब तक कि एक थ्रेड अपना ज्यादा समय इंतजार नहीं कर रहा है, तब आप अधिक होने का औचित्य साबित कर सकते हैं। अपने स्वयं के धागे में प्रत्येक अनुरोध को चलाना एक बुरा विचार है, क्योंकि संदर्भ स्विच घटित होगा और संसाधन बर्बाद होगा। (यदि आप मेरे द्वारा लिखी गई हर चीज को देखना चाहते हैं, तो संपादित करें पर क्लिक करें और इस पोस्ट के पिछले संशोधनों को देखें। मैंने इसे हटा दिया क्योंकि यह केवल मुख्य मुद्दे को हाथ में लेने के लिए प्रतीत होता है।)
आप इन अनुरोधों को थ्रेड्स में निश्चित रूप से कर सकते हैं, यदि आप प्रति सेकंड बड़ी संख्या में अनुरोध करना चाहते हैं। हालाँकि, थ्रेड निर्माण के साथ ओवरबोर्ड न जाएं। एक संतुलन खोजें और इसके साथ रहें। यदि आप एक अतुल्यकालिक मॉडल बनाम एक तुल्यकालिक का उपयोग करते हैं तो आपको बेहतर प्रदर्शन मिलेगा।
मुझे आशा है कि वह मदद करेंगे।