एक थ्रेड पूल क्या है?

थ्रेड पूल परिभाषा

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

यह पैटर्न थ्रेड जीवनचक्र ओवरहेड को कम करता है और सीमाओं, अनुसूचियों, बंद होने, और परिणाम प्रबंधन को केंद्रीकृत करता है। निष्पादक का अमूर्तता थ्रेड के रूप में उतनी ही महत्वपूर्ण है क्योंकि कॉलर को कार्य को सबमिट करने और सीधे कार्यकर्ता निर्माण के बिना पूर्णता को देखने के लिए एक परिभाषित तरीका चाहिए। यहां उपयोग की जाने वाली प्राथमिक शब्दावली Python concurrent futures documentationके अनुसार है, जो अवधारणा को एक ठोस तकनीकी सीमा देता है न कि इसे एक मार्केटिंग लेबल के रूप में मानता है।

एक उपयोगी परिभाषा यह भी बताती है कि अवधारणा क्या नहीं करती। एक थ्रेड पूल स्वचालित रूप से समानांतर गति में सुधार, एक असीमित कार्य बफर, या दर नियंत्रण के लिए एक विकल्प नहीं है। Runtime सीमाएँ और कार्यभार व्यवहार तय करते हैं कि कार्यकर्ता एक साथ निष्पादित करते हैं या नहीं और क्या डाउनस्ट्रीम सिस्टम उनके आउटपुट को स्वीकार कर सकते हैं। उस सीमा को स्पष्ट बनाए रखना आर्किटेक्चर आरेखों को एक घटक को किसी अन्य परत से संबंधित बनाने से रोकता है।

एक थ्रेड पूल कार्यों को कैसे संसाधित करता है

एक पूल अनियमित कार्य आगमन को नियंत्रित कार्यकर्ता निष्पादन में परिवर्तित करता है। सबमिशन, कतारबद्धता, कार्य, पूर्णता, और बंद होना प्रत्येक को एक स्पष्ट नीति की आवश्यकता है।

1. एक कॉलर कार्य को एक काल करने योग्य या कार्य वस्तु के रूप में पैकेज करता है जिसमें उसे आवश्यक डेटा होता है।
2. निष्पादक केवल तभी कार्य को स्वीकार करता है जब प्रवेश नीति और जीवनचक्र की स्थिति इसकी अनुमति देती है।
3. एक कतार स्वीकृत कार्य को धारण करती है जब तक कि कोई कार्यकर्ता उपलब्ध नहीं हो जाता, जब तक कि डिजाइन कार्य को सीधे एक निष्क्रिय कार्यकर्ता को नहीं सौंपता।
4. कार्यकर्ता कार्य को निष्पादित करता है और संबंधित पूर्णता हैंडल में एक परिणाम या अपवाद संग्रहीत करता है।
5. निष्पादक कार्यकर्ता को पूल में वापस लौटाता है, परिणाम को उजागर करता है, और अंततः एक व्यवस्थित बंद होता है।

स्थिर पूल सक्रिय थ्रेड पर कैप सेट करते हैं, कैश्ड डिजाइन कार्यकर्ता की संख्या को भिन्न करते हैं, और कार्य-चोरी डिजाइन निष्क्रिय कार्यकर्ताओं को आस-पड़ोस की कतारों से कार्य लेने देते हैं। नाम रंटाइम में भिन्न होते हैं, लेकिन हर कार्यान्वयन कतारबद्धता, कार्यकर्ता निर्माण, अस्वीकार और जीवनचक्र के बारे में विकल्प बनाता है। इस व्यवहार को अधिक विस्तार से दस्तावेजीकृत किया गया है Java ThreadPoolExecutor documentation। स्रोत उपयोगी है क्योंकि यह वास्तविक निष्पादन या डेटा मॉडल का वर्णन करता है न कि ढीली उपमा पर भरोसा करता है।

थ्रेड पूल घटक

क्यू को एक कार्यान्वयन विवरण के रूप में मानना ओवरलोड का एक सामान्य स्रोत है। एक अनसীমित क्यू सक्रिय थ्रेड की संख्या को स्थिर रख सकता है जबकि विलंब और मेमोरी बिना किसी दृश्यमान छत के बढ़ती है। एक सीमित क्यू दबाव को स्पष्ट बनाता है और सिस्टम को एक प्रतिक्रिया चुनने के लिए मजबूर करता है।

थ्रेड पूल कहाँ फिट होते हैं

इन उपयोग मामलों में एक चयन नियम साझा होता है: एक थ्रेड पूल चुनें क्योंकि इसका निष्पादन और स्वामित्व मॉडल कार्यभार से मेल खाता है, न कि नाम सुनने में अधिक उन्नत लगता है। लंबे समय तक चलने वाली सेवाएँ, कार्य जो एक ही छोटे पूल में अन्य कार्यों के लिए इंतजार करते हैं, और अत्यधिक CPU-बाउंड पायथन कोड को अलग संरचनाओं की आवश्यकता हो सकती है। पूल को अवरुद्ध व्यवहार से मेल खाना चाहिए न कि सतही सिंटैक्स से।

आकार और क्यू नीति

पूल का आकार उपयोगी ओवरलैप को कंटेंशन और संसाधन लागत के खिलाफ संतुलित करता है। कार्यों में CPU समय, प्रतीक्षा समय, मेमोरी, फ़ाइल वर्णनकर्ता, और डाउनस्ट्रीम प्रभाव में भिन्नता के कारण कोई सार्वभौमिक श्रमिक संख्या नहीं है।

• सेवा और प्रतीक्षा समय मापें। एक कार्य जो अपने जीवनकाल का अधिकांश समय प्रतीक्षा करता है, CPU को संतृप्त करने वाले कार्य की तुलना में अधिक श्रमिकों को सहन कर सकता है।
• क्यू को सीमित करें। सीमित क्षमता ओवरलोड को एक नीति निर्णय में बदल देती है इससे पहले कि मेमोरी एकमात्र सीमा बन जाए।
• नैस्टेड प्रतीक्षा से बचें। एक श्रमिक जो समान थका हुआ पूल में प्रस्तुत अन्य कार्य के लिए प्रतीक्षा करता है, डेडलॉक कर सकता है।
• कार्य थ्रेड का नाम दें। उपयोगी नाम स्टैक ट्रेस और मैट्रिक्स को स्वामी पूल और कार्यभार से जोड़ते हैं।
• शटडाउन परिभाषित करें। चुनें कि क्या कतारबद्ध कार्य पूरा होता है, रद्द किया जाता है, या किसी अन्य दीर्घकालिक प्रणाली को सौंपा जाता है।

प्रतिनिधि ट्रैफिक के साथ ट्यून करें, फिर केवल कार्यकर्ता संख्या के बजाय क्यू आयु पर नज़र रखें। बढ़ती क्यू आयु का अर्थ है कि स्वीकार किए गए कार्य अधिक समय तक प्रतीक्षा कर रहे हैं भले ही थ्रूपुट स्थिर प्रतीत हो। यह संकेत अक्सर उपयोगकर्ता-सामना करने वाले टाइमआउट या मेमोरी अलार्म से पहले पहुंचता है। संबंधित प्राइमरी संदर्भ है Windows थ्रेड-पूल आर्किटेक्चर मार्गदर्शिका, जो उस विकल्प के पीछे की संग्रहण, निष्पादन, या अंतःक्रियाशीलता धारणाओं को स्पष्ट करता है।

थ्रेड पूल विफलता मोड

थ्रेड पूल चुपचाप विफल होते हैं जब उनके सीमाएँ केवल सक्रिय श्रमिकों पर होती हैं। प्रतीक्षा कर रहे कार्य, डाउनस्ट्रीम कनेक्शन, और कार्य-स्वामित्व मेमोरी उस दृश्य संख्या से बाहर बढ़ते रह सकते हैं।

• अनसिमित सबमिशन। एक तेज निर्माता एक लंबी कतार बना सकता है जिसका सबसे पुराना कार्य उसके शुरू होने से पहले अप्रचलित हो जाता है।
• पूल-आंतरिक निर्भरता। एक ही थका हुआ पूल से भविष्य पर प्रतीक्षा कर रहे श्रमीकों को आवश्यक कार्य के चलने से रोक सकते हैं।
• छिपा हुआ अवरोध। एक कार्य जो छोटा बताया गया है, वह अपने जीवन के अधिकांश समय के लिए DNS, संग्रहण, एक लॉक, या एक दूरस्थ कोटा पर प्रतीक्षा कर सकता है।
• साझा क्लाइंट का दुरुपयोग। एक पुस्तकालय वस्तु समकालिक पहुँच के लिए सुरक्षित नहीं हो सकती है भले ही स्वयं पूल सही हो।
• अचानक शटडाउन। पूर्णता नीति के बिना श्रमिकों को रोकने से आंशिक लेखन, पट्टे, या बाहरी सत्र सक्रिय रह सकते हैं।

एक विफलता को सबसे छोटे जिम्मेदार परत तक ट्रेस किया जाना चाहिए। जब विलंब बढ़ता है, तो क्यू आयु और अवरुद्ध स्टैक्स की जांच करें; जब CPU बढ़ता है, तो कार्य की लागत और लॉक कंटेंशन की जांच करें; जब निर्भरता धीमी होती है, तो पूल का आकार बढ़ाने से पहले प्रवेश को कम करें। यह प्रथा एक स्पष्ट उपचारात्मक कार्रवाई उत्पन्न करती है बजाय इसके कि अधिक क्षमता जोड़ने के लिए एक अस्पष्ट निर्देश हो।

वेब संग्रह में थ्रेड पूल

एक वेब- संग्रह पूल को छोटे, स्वतंत्र कार्य प्रस्तुत करने चाहिए जिनके आउटपुट में स्रोत URL और कार्य पहचानकर्ता होते हैं। पूल स्थानीय ओवरलैप का प्रबंधन करता है; यह किसी होस्ट को ओवरलोड करने की अनुमति नहीं देता या API की सेवा अनुबंध की अनदेखी नहीं करता।

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

स्क्रेपलेस प्रबंधित वेब- संग्रह चरण को संभालता है जैसा कि उद्घाटन वाक्य में वर्णित है। अनुप्रयोग अभी भी स्रोत स्वीकृति, क्षेत्र परिभाषाएं, कार्यभार की सीमाएँ, संरक्षण, पहुंच नियंत्रण, और मान्यता का मालिक है। कार्यकारी स्थानीय श्रमिकों का मालिक है, जबकि अनुप्रयोग प्रति-होस्ट निष्पक्षता, संग्रह सीमा, दूरस्थ सीमाएँ, और क्या कतारबद्ध कार्य अभी भी मूल्यवान है का मालिक है। उन परतों के बीच एक स्पष्ट अनुबंध बाद में परिवर्तनों को परीक्षण में आसान बनाता है।

पाइपलाइन को उपयोग केस की आवश्यकता के अनुसार ऑडिटेबिलिटी के लिए कच्चे साक्ष्य और क्यूरेटेड आउटपुट दोनों को बनाए रखना चाहिए। कच्चा सामग्री एक वाक्याश्रय या स्कीमा बदलने के बाद पुनः प्रसंस्करण का समर्थन करता है; क्यूरेटेड टेबल स्थिर विश्लेषण का समर्थन करते हैं। संग्रहित सामग्री को केवल तब संग्रहीत करें जब यह सुनिश्चित किया गया हो कि अंतिम पृष्ठ वह पृष्ठ है जिसे इरादा है और कि आवश्यक फ़ील्ड मौजूद हैं। दोनों प्रदर्शनों का उत्तर विभिन्न संचालन संबंधी प्रश्नों का है और उन्हें डुप्लिकेट के रूप में गलत नहीं समझा जाना चाहिए।

थ्रेड पूल समीक्षा चेकलिस्ट

डिज़ाइन समीक्षा के दौरान निम्नलिखित प्रश्नों का उपयोग करें। एक लिखित उत्तर एक अनुमानित डिफ़ॉल्ट से अधिक मूल्यवान होता है क्योंकि यह उस जगह को उजागर करता है जहां टीमें थ्रेड पूल के बारे में असहमत होती हैं।

• कोई अधिकतम कतार क्षमता और अधिकतम कतार आयु क्या है?
• क्या एक कार्य उसी पूल में दूसरे कार्य की प्रतीक्षा कर सकता है?
• कौन सी प्रक्रियाएँ अवरुद्ध होती हैं, और उन प्रतीक्षा को क्या मुक्त करता है?
• परिणाम, अपवाद, और रद्दकरण का प्रतिनिधित्व कैसे किया जाता है?
• क्या साझा क्लाइंट और पार्सर थ्रेड-सुरक्षित के रूप में प्रलेखित हैं?
• कौन सी दूरस्थ सेवा सीमाएँ कार्यकर्ता की गिनती से स्वतंत्र रूप से लागू होती हैं?
• कौन से मैट्रिक्स संतृप्ति को उपयोगकर्ता-समक्ष विफलता से पहले उजागर करते हैं?
• शटडाउन कतारबद्ध और सक्रिय कार्य को कैसे संभालता है?

एक थ्रेड पूल उत्पादन के लिए तैयार है जब इसकी कतार, अस्वीकृति व्यवहार, कार्य स्वामित्व, निगरानी और शटडाउन पथ उसके कार्यकर्ता की संख्या के रूप में जानबूझकर होते हैं। कार्यभार के आकार, डेटा मात्रा, सेवा सीमाओं, या उपभोक्ता अपेक्षाओं के बदलने के बाद उत्तरों पर दोबारा गौर करें। एक आर्किटेक्चर जो अन्वेषणात्मक बैच के लिए समझदारी थी, वह निरंतर उत्पादन पथ के लिए खराब फिट हो सकती है।

निष्कर्ष

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

संदर्भ

• स्क्रेपलेस स्क्रेपिंग ब्राउज़र गेटिंग-स्टार्टेड डोक्यूमेंटेशन
• स्क्रेपलेस स्क्रेपिंग ब्राउज़र प्रोडक्ट ओवरव्यू
• स्क्रेपलेस सीमित ए.आई. डेटा पाइपलाइनों के लिए गाइड
• स्क्रेपलेस ओपन-सोर्स प्रोजेक्ट्स पर GitHub