TNonblockingServer, TThreadedServer और TThreadPoolServer, जो मेरे मामले के लिए सबसे अच्छा फिट बैठता है?

Question

हमारा विश्लेषणात्मक सर्वर सी ++ में लिखा गया है। यह मूल रूप से अंतर्निहित स्टोरेज इंजन से पूछताछ करता है और बहाव के माध्यम से काफी बड़े संरचित डेटा देता है। एक सामान्य अनुरोध को पूरा करने के लिए लगभग 0.05 से 0.6 सेकंड लगेंगे अनुरोध आकार पर निर्भर करता है।

मैंने देखा कि कुछ विकल्प हैं जिनके संदर्भ में हम सी ++ कोड, विशेष रूप से TNonblockingServer, TThreadedServer, और TThreadPoolServer में उपयोग कर सकते हैं। ऐसा लगता है कि TNonblockingServer जाने का तरीका है क्योंकि यह अधिक समवर्ती अनुरोधों का समर्थन कर सकता है और अभी भी कार्यों के माध्यम से क्रंच करने के लिए दृश्य के पीछे एक थ्रेड पूल का उपयोग कर सकता है। यह धागे के निर्माण/विनाश की लागत से भी बचाता है।

बचत पर फेसबुक के अद्यतन: http://www.facebook.com/note.php?note_id=16787213919

यहाँ फेसबुक पर, हम सी के लिए एक पूरी तरह से अतुल्यकालिक क्लाइंट और सर्वर पर काम कर रहे ++। यह सर्वर वर्तमान TNonblockingServer की तरह ईवेंट-संचालित I/O का उपयोग करता है, लेकिन इसका इंटरफ़ेस पर एप्लिकेशन कोड सभी एसिंक्रोनस कॉलबैक पर आधारित है। यह हमें सर्वर लिखने की अनुमति देगा जो हजारों एक साथ अनुरोधों की सेवा कर सकता है (जिनमें से प्रत्येक को अन्य थ्रिफ्ट या मेमकैच सर्वर पर कॉल करने की आवश्यकता है) केवल कुछ धागे के साथ।

stackover पर संबंधित पोस्ट: Large number of simulteneous connections in thrift

कहा जा रहा है, वहीं यह आवश्यक नहीं वास्तव में तेजी से काम करते हैं (संचालकों अभी भी एक थ्रेड पूल में अमल) करते हैं करने के लिए सक्षम नहीं होगा, लेकिन अधिक ग्राहकों हो जाएगा एक बार में आपसे जुड़ने में सक्षम

बस सोच रहा है कि क्या कोई अन्य कारक हैं जो मैं यहां याद कर रहा हूं? मैं कैसे तय करूं कि कौन मेरी आवश्यकताओं को सर्वोत्तम बनाता है?

Answer 1

अनुरोध जो पूरा होने के लिए 50-600 मिलीसेकंड लेते हैं, वे बहुत लंबे हैं। थ्रेड बनाने या नष्ट करने में लगने वाला समय उस से बहुत कम है, इसलिए इस समय अपने फैसले को उस कारक में न दें। मैं उस व्यक्ति को चुनूंगा जो समर्थन करने में सबसे आसान है और यह कम से कम त्रुटि-प्रवण है। आप सूक्ष्म concurrency कीड़े की संभावना को कम करना चाहते हैं।

यही कारण है कि सिंगल-थ्रेडेड ट्रांज़ेक्शन हैंडलिंग कोड लिखना अक्सर आसान होता है, जहां इसे अवरुद्ध करना होता है, और इनमें से कई समानांतर में चल रहे हैं, अधिक जटिल गैर-अवरोध मॉडल के मुकाबले। एक अवरुद्ध धागा एक व्यक्तिगत लेनदेन को धीमा कर सकता है, लेकिन यह सर्वर को प्रतीक्षा करते समय अन्य काम करने से नहीं रोकता है।

यदि आपका लेनदेन भार बढ़ता है (यानी अधिक ग्राहक लेनदेन) या अनुरोध प्रक्रिया के लिए तेजी से हो जाते हैं (प्रति लेनदेन 1 मिलीसेकंड तक पहुंचते हैं), तो लेनदेन ओवरहेड एक कारक बन जाता है। ध्यान देने के लिए मीट्रिक थ्रूपुट है: प्रति इकाई समय कितने लेनदेन पूर्ण होते हैं। एक लेनदेन की पूर्ण अवधि उस दर से कम महत्वपूर्ण होती है, जिस पर वे पूरा हो रहे हैं, कम से कम यदि यह एक सेकंड से नीचे रहता है।

Answer 2

एक Github पर पुरुष एक अच्छा तुलना

TThreadedServer

TThreadedServer बना दिया है प्रत्येक ग्राहक के कनेक्शन के लिए एक नया थ्रेड spawns, और जब तक ग्राहक कनेक्शन बंद कर दिया है प्रत्येक थ्रेड जिंदा रहता है।इसका मतलब है कि यदि 1000 समवर्ती ग्राहक कनेक्शन हैं, तो TThreadedServer को 1000 थ्रेड एक साथ चलाने की आवश्यकता है।

TNonblockingServer

TNonblockingServer एक धागा नेटवर्क आई/ओ के लिए समर्पित है। एक ही धागा अनुरोधों को संसाधित भी कर सकता है, या आप अनुरोध प्रसंस्करण के लिए कार्यकर्ता धागे का एक अलग पूल बना सकते हैं। सर्वर कई समवर्ती कनेक्शनों को एक छोटी संख्या के थ्रेड के साथ संभाल सकता है क्योंकि इसे प्रत्येक कनेक्शन के लिए एक नया धागा बनाने की आवश्यकता नहीं होती है।

TThreadPoolServer (यहाँ नहीं बेंचमार्क)

TThreadPoolServer TThreadedServer के समान है; प्रत्येक क्लाइंट कनेक्शन को अपना समर्पित सर्वर थ्रेड मिलता है। यह TThreadedServer से 2 तरीकों से अलग है:

क्लाइंट थ्रेड पूल पर वापस जाता है जब ग्राहक पुन: उपयोग के लिए कनेक्शन बंद कर देता है। धागे की संख्या पर एक सीमा है। थ्रेड पूल सीमा से आगे नहीं बढ़ेगा। थ्रेड पूल में कोई और थ्रेड उपलब्ध नहीं होने पर क्लाइंट लटकता है। अन्य 2 सर्वर की तुलना में उपयोग करना अधिक कठिन है।