IIS 7.x एप्लीकेशन पूल बेस्ट प्रैक्टिस

Question

हम कुछ नए सर्वरों के लिए साइटों का एक समूह तैनात करने वाले हैं। मेरे पास अनुप्रयोग पूल के बारे में निम्नलिखित प्रश्न हैं:

1. प्रति वेबसाइट एक आवेदन पूल रखना उचित है। क्या इस दृष्टिकोण के लिए कोई चेतावनी है? क्या एक एप्लिकेशन पूल सभी सीपीयू, मेमोरी, आदि को हॉग करेगा ...?

2. आपको एक आवेदन पूल में कई कार्यकर्ता प्रक्रियाओं की अनुमति कब देनी चाहिए? आपको कब नहीं करना चाहिए?

3. क्या निजी मेमोरी सीमा का उपयोग एक अनुप्रयोग पूल को दूसरे के साथ हस्तक्षेप करने से रोकने के लिए किया जा सकता है? क्या यह उचित प्रतिक्रिया प्राप्त किए बिना एप्लिकेशन पूल को रीसायकल करने के लिए वैध अनुरोधों को कम करने का कारण होगा?

4. निजी और आभासी मेमोरी सीमा के बीच अंतर क्या है?

5. क्या प्रति साइट एक एप्लिकेशन पूल को चलाने के लिए बाध्यकारी कारण नहीं हैं?

Comments

सबसे पहले आप पर सवाल: क्या ये वेब साइट्स हैं (यानी: .htm / .js), या वेब एप्लिकेशन (यानी .aspx / .php)?

— गोरिल्ला

अधिकतर .Net 3.5 अनुप्रयोग। एक एक तीसरे पक्ष के PHP आवेदन है।

— एरिक बुरचम

यह विषयों की एक विस्तृत श्रृंखला की तरह है - विषय (और @ कोडिंगगोरिला के उत्तर) दिलचस्प हैं, लेकिन यह एसएफ के क्यू-एंड-ए स्टाइल के लिए सबसे अच्छा फिट नहीं हो सकता है

— voretaq7

Answer 1

1) प्रति वेबसाइट पर एक आवेदन पूल होना उचित है। क्या इस दृष्टिकोण के लिए कोई चेतावनी है? क्या एक आवेदन पूल, उदाहरण के लिए, सभी सीपीयू, मेमोरी, आदि को हॉग कर सकता है ...?

यह एक बहुत अच्छा दृष्टिकोण है; कोई भी अच्छा कारण नहीं है कि मैं अलग-अलग "साइट्स" (एप्लिकेशन) एक ही पूल साझा करने के लिए सोच सकता हूं। जब तक कि उन्हें किसी प्रकार का एकल संसाधन साझा करने की आवश्यकता न हो। एक आवेदन सैद्धांतिक रूप से बहुत सारे सीपीयू या मेमोरी को हॉग कर सकता है, लेकिन अनुप्रयोगों को पूल करने के तरीके को बदलने से वास्तव में यह बहुत प्रभावित नहीं होगा।

2) आपको एक आवेदन पूल में कई कार्यकर्ता प्रक्रियाओं की अनुमति कब देनी चाहिए। आपको कब नहीं करना चाहिए?

डिफ़ॉल्ट सेटिंग्स का उपयोग करके इसे अकेले छोड़ दिया जाता है। जब तक आप वास्तव में यह नहीं जानते कि आप जो कर रहे हैं वह वास्तव में आपकी वेबसाइट / एप्लिकेशन को नकारात्मक रूप से प्रभावित कर सकता है।

3) क्या एक एप्लिकेशन पूल को दूसरे के साथ हस्तक्षेप करने से रोकने के लिए निजी मेमोरी सीमा का उपयोग किया जा सकता है? क्या यह उचित प्रतिक्रिया प्राप्त किए बिना एप्लिकेशन पूल को रीसायकल करने के लिए वैध अनुरोधों को कम करने का कारण होगा?

a) सैद्धांतिक रूप से

b) हाँ इसे कम करने के लिए सेट करने से नकारात्मक प्रभाव पड़ सकता है। फिर से, जब तक कि आपके पास विशिष्ट आवश्यकताएं न हों, और यह जान लें कि आप क्या कर रहे हैं, बस इन्हें अकेला छोड़ दें।

4) निजी और आभासी मेमोरी सीमा के बीच अंतर क्या है?

यह बहुत जटिल है, यहाँ एक त्वरित पोस्ट है जो मैंने पाया कि मदद कर सकता है: http://cybernetnews.com/cybernotes-windows-memory-usage-explained/

5) क्या प्रति साइट एक एप्लिकेशन पूल को चलाने के लिए बाध्यकारी कारण नहीं हैं?

फिर से, केवल इस कारण से मैं सोच सकता हूं कि अगर किसी तरह के "साझा संसाधन" की जरूरत है, तो कई अनुप्रयोगों की जरूरत है, तो आप उन्हें उसी प्रक्रिया में चलाना चाहेंगे।

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

****अद्यतन करें****

# 2 पर अतिरिक्त जानकारी के लिए आपके अनुरोध के संबंध में, आपको ऐसा नहीं करना चाहिए जब तक कि आपको ऐसा करने की कोई विशिष्ट आवश्यकता न हो। यहां तक ​​कि सर्वर क्रियाओं में जो एक लंबा समय लेती हैं, अनुरोधों को कई थ्रेड्स का उपयोग करके प्रस्तुत किया जाता है, और आप लंबे चलने वाले कार्यों को संभालने के लिए "Async अनुरोध" का उपयोग करना चाहते हैं (जो अन्य अनुरोधों को संभालने के लिए थ्रेड पूल थ्रेड को मुक्त करता है)। यथार्थवादी रूप से, मैं किसी एकल पूल के लिए कई प्रक्रियाओं की अनुमति देने के किसी भी अच्छे कारण के बारे में नहीं सोच सकता।

एक बार जब आप कई प्रक्रियाएं शुरू करना शुरू कर देते हैं, तो आप संभावित रूप से चीजों में भाग लेते हैं: सत्र की स्थिति खोना क्योंकि सत्र 1 प्रक्रिया में जीवित है, लेकिन अनुरोध प्रक्रिया 2 द्वारा संभाला जा रहा है। या इससे भी बदतर, आपको यह पता लगाना है कि कैसे कुछ अंतर-प्रक्रिया संचार करें, जो एक वास्तविक दर्द है।

कोई फर्क नहीं पड़ता कि आप कई प्रक्रियाओं के लिए एक कारण के संबंध में आते हैं, मैं शर्त लगाने के लिए तैयार रहूंगा कि इससे निपटने का एक बेहतर तरीका है (एक अन्य प्रक्रिया को पूरा करने के बजाय)।

Comments

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

— एरिक बुरचम

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

— ट्रिस्टनके

@TristanK, टिप के लिए धन्यवाद। जो बेहद मददगार था।

— एरिक बुरचम

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

— एरिक बुरचम

@Coding गोरिल्ला - जारी ... सबसे अच्छा "कारण" मुझे कई कार्यकर्ता प्रक्रिया सुविधा का उपयोग करने के लिए प्रदर्शन को बढ़ाने के लिए मिला है। इस लिंक को देखें: iis-aid.com/articles/performance_testing/… । बेशक, आपको बेहतर पता था कि आप प्रोग्रामिंग के सभी अतुल्यकालिक पहलुओं के साथ क्या कर रहे हैं जो हम अक्सर वेबसाइटों के साथ खाते में लेने की उपेक्षा करते हैं, क्योंकि उनमें से अधिकांश (कम से कम शुरू करने के लिए) एक एकल श्रमिक धागा चलाते हैं। इसलिए मेरे प्रश्न का संक्षिप्त उत्तर है: यदि आपको प्रदर्शन की समस्या हो रही है, तो इसे आज़माएँ।

— एरिक बुरचम

Answer 2

मैं हमेशा एक वेब साइट के लिए एक समर्पित एप्लिकेशन पूल कॉन्फ़िगर करता हूं। निम्न-लागत वाली वेब साइट होस्टिंग परिदृश्य ऐसे हैं जहां प्रति पूल बड़ी संख्या में साइटें होने से समझ में आता है।

किसी साइट को सभी सिस्टम संसाधनों का उपभोग करने से रोकने के लिए स्मृति सीमा वास्तव में केवल आदिम सुरक्षा सीमाएं हैं। ध्यान दें कि यह IIS 6.0 x86 की तुलना में Windows 2008 R2 x64 पर संभावित समस्या का अधिक है, क्योंकि x86 अनुप्रयोगों में प्राकृतिक 2 डी मेमोरी छत थी। भारी मात्रा में मेमोरी का उपभोग करने के लिए मेमोरी लीक वाले एप्लिकेशन के लिए IIS 7.5 पर यह बहुत आसान है।

मैं भी अनुप्रयोग पूल रीसाइक्लिंग का एक बड़ा प्रशंसक नहीं हूँ। अगर मेरे पास एप्लिकेशन पूल है और मैं केवल एप्लिकेशन चला रहा हूं, अगर हमारे कोड में कुछ भी गलत नहीं है, तो शायद ऐप पूल को रीसायकल करने की कोई आवश्यकता नहीं है। और यदि आवेदन में कोई दोष है, तो कोड को ठीक करने के लिए अंतिम उचित कार्रवाई होगी।

Comments

स्मृति पर 32 बिट कैप इंगित करने के लिए धन्यवाद। मुझे नहीं पता कि मैं इन चीजों को कैसे भूल जाऊं। मुझे लगता है कि सही दृष्टिकोण अगर आपके पास एप्लिकेशन पूल को क्रैश करने के लिए पर्याप्त अनुप्रयोग है, तो इसे ठीक करना है, यह मानते हुए कि आपके पास कोड तक पहुंच है। मैं सलाह की सराहना करता हूं!

— एरिक बुरचम

हमने अपना खुद का कुछ परीक्षण किया। एप्लिकेशन पूल चलाने से लगता है कि एक ही एप्लिकेशन पूल में सभी एप्लिकेशन को चलाने के ऊपर लगभग 64K प्रति ऐप पूल का ओवरहेड है। यह स्मृति की खपत की निगरानी के लिए प्रदर्शन मॉनिटर का उपयोग करते हुए 12 घंटे की एक नमूना अवधि से अधिक है। यह 64-बिट सर्वर पर था। मुझे लगता है कि अगर यह सरल परीक्षण सही हो जाता है, तो प्रति एप्लिकेशन एक एप्लिकेशन पूल की संसाधन लागत मूल रूप से आधुनिक हार्डवेयर पर नगण्य है।

— एरिक बुरचम