2015-03-16 4 views
5

वेबसाइट पर परिवर्तनों को तैनात करने का सबसे अच्छा तरीका क्या है (डीएलएस और अन्य आवश्यक फाइलों को प्रतिस्थापित करें)?वेबसाइट को तैनात करने का सबसे अच्छा तरीका - ऐप पूल स्टार्ट स्टॉप या वेबसाइट स्टार्ट स्टॉप

क्या वेबसाइट को रोका जाना चाहिए और शुरू करना चाहिए या ऐप पूल को रोका जाना चाहिए या शुरू करना चाहिए?

मैंने पढ़ा कि जब कोई वेबसाइट रुक जाती है, तब भी इसमें स्मृति स्थिति लोड हो जाती है। इस मामले में पुराना अनुरोध किया जाएगा? क्या किसी भी समस्या के बिना डीएलएस को बदला जा सकता है? वेबसाइट शुरू होने पर सामग्री को फिर से लोड किया जाता है?

जब ऐप पूल बंद हो जाता है, तो क्या यह पुराने अनुरोधों को जारी रखेगा? यदि हां, तो पुराने अनुरोध को कैसे सेवा दी जाती है क्योंकि वेबसाइट में अब बदले गए डीएलएस हैं?

उत्तर

4

किसी वेबसाइट में परिवर्तनों को तैनात करने का सबसे अच्छा तरीका क्या है (डीएलएस और अन्य आवश्यक फ़ाइलों को प्रतिस्थापित करें)?

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

क्या वेबसाइट को रोका जाना चाहिए और शुरू करना चाहिए या ऐप पूल को रोका जाना चाहिए या शुरू करना चाहिए?

आपको आमतौर पर ऐसा करने की ज़रूरत नहीं है। हालांकि, अगर आप अपग्रेड के दौरान अपनी वेबसाइट तक पहुंच को रोकना चाहते हैं और अपग्रेड को कुछ सेकंड से अधिक समय लगने की उम्मीद है, तो आप वेब साइट को रोक सकते हैं और एक ही आईआईएस बाइंडिंग का उपयोग कर सकते हैं जो "रखरखाव के तहत आवेदन" " संदेश।

मैंने पढ़ा कि जब कोई वेबसाइट रुक जाती है, तब भी इसमें स्मृति स्थिति लोड हो जाती है। इस मामले में पुराना अनुरोध किया जाएगा? क्या किसी भी समस्या के बिना डीएलएस को बदला जा सकता है? वेबसाइट शुरू होने पर सामग्री को फिर से लोड किया जाता है?

HTTP प्रोटोकॉल स्टेटलेस है। इसलिए, अद्यतन की जाने वाली अधिकांश सामग्री सर्वर पर नई फ़ाइलों से पुनः लोड की जाएगी।

कुछ अपवाद हैं।

यदि आप out-of-process session state का उपयोग कर रहे हैं, तो भी राज्य जारी रहेगा, भले ही एप्लिकेशन को दोबारा बनाया गया हो और पुनः लोड किया गया हो। आम तौर पर, सत्र स्थिति में आपके पास जो डेटा है, वह कुछ ऐसा है जो आप अपग्रेड करना चाहते हैं।

यदि आप कैशिंग (System.Web.Caching या System.Runtime.Caching) का उपयोग कर रहे हैं, तो कैश किया गया डेटा तब भी रहेगा जब आपने इसे "हटाने योग्य नहीं" बनाने के लिए निर्दिष्ट किया था। आम तौर पर, मैं कैश निर्भरता के रूप में एप्लिकेशन के लिए एक फ़ाइल का उपयोग करता हूं, इसलिए जब उस फ़ाइल को सर्वर पर संपादित (या प्रतिस्थापित) किया जाता है, तो कैश रीसेट हो जाएगा।

आउटपुट कैशिंग में कैश निर्भरता नहीं है। आमतौर पर यह तब तक जीवित रहता है जब तक कि एप्लिकेशन पूल पुनरारंभ नहीं होता है। लेकिन, आप this answer को मैन्युअल तरीके से एप्लिकेशन पूल रीसेट के बिना रीसेट करने के लिए देख सकते थे।

कुकीज़ दूरस्थ क्लाइंट मशीनों पर संग्रहीत हैं। इसलिए, वे एक अपग्रेड बरकरार रहेंगे।

स्टेटिक फ़ाइलें (छवियां, सीएसएस, और जावास्क्रिप्ट फ़ाइलें) आमतौर पर रिमोट क्लाइंट मशीनों पर कैश की जाती हैं। तो जब आप अपग्रेड करते हैं, तो कैश की गई फ़ाइल का उपयोग नहीं किया जाता है, यह सुनिश्चित करने के लिए इन यूआरएल के अंत में एक क्वेरी स्ट्रिंग को जोड़ना सहायक होता है। इस तरह के दृष्टिकोण के लिए this article देखें।

जब ऐप पूल बंद हो जाता है, तो क्या यह पुराने अनुरोधों को जारी रखेगा? यदि हां, तो पुराने अनुरोध को कैसे सेवा दी जाती है क्योंकि वेबसाइट में अब बदले गए डीएलएस हैं?

जैसा कि मैंने पहले ही उल्लेख किया है, HTTP प्रोटोकॉल स्टेटलेस है। सर्वर ग्राहकों द्वारा किए गए किसी भी पूर्व अनुरोध को फिर से नहीं चलाएगा। एक बार क्लाइंट को रिपस्पॉन्स प्राप्त हो जाने के बाद, सर्वर अनिवार्य रूप से उनके बारे में भूल जाता है।

वेब सर्वर एक अपग्रेड को संभालने का एक तरीका यह निर्धारित करता है कि यह एक वेब एप्लिकेशन या वेबसाइट है (और यदि कोई वेबसाइट, चाहे इसे प्रीकंपल किया गया हो)। यदि एप्लिकेशन अपग्रेड के दौरान चल रहा है, तो उपयोगकर्ता जो इसे एक्सेस करने का प्रयास करते हैं, वे त्रुटियां देख सकते हैं।

मेरी सलाह है: इसके बारे में चिंता न करें। ऑफ-पीक टाइम्स के लिए अपने अपग्रेड शेड्यूल करें। अपग्रेड विंडो को यथासंभव छोटा बनाने के लिए प्रक्रिया को स्वचालित करने के लिए वेब परिनियोजन का उपयोग करें। और कैश किए गए डेटा और सामग्री को उचित रूप से रीसेट करने के लिए उपर्युक्त तकनीकों का उपयोग करें। अधिकांश अनुप्रयोगों में, रात के मध्य में डाउनटाइम के कुछ सेकंड या मिनट लगभग अनजान होते हैं।

+0

उत्तर के लिए धन्यवाद। हमारे मामले में हमारे पास तैनाती के लिए कोई रखरखाव विंडो नहीं है, इसलिए ऑफ़लाइन संदेश एक नहीं है हमारे लिए विकल्प। हम एलबी से सर्वरों का बैच लेते हैं और फिर कनेक्शन को निकालने की प्रतीक्षा करते हैं। जब कनेक्शन बहुत कम होते हैं, तो हम शुरू करते हैं इन सर्वरों पर तैनाती। तो मैं समझना चाहता था कि इस मामले में, तैनाती के लिए सबसे अच्छा तरीका क्या है? यदि ऐप पूल बंद कर दिया गया है और फिर शुरू किया गया है, तो पुराने कनेक्शन के साथ क्या होता है जो तैनाती शुरू होने पर अभी भी वहां थे? क्या वे परोसा जाएगा या नहीं? – Tulika

+0

ऐप पूल रीसायकल के मामले में, मांग रीसायकल के कारण, पुराने कनेक्शन परोसा जाना चाहिए। लेकिन मैं समझना चाहता हूं कि जब मैंने वेबसाइट फ़ोल्डर में डीएलएस को बदल दिया है, पुराने कनेक्शन के लिए अनुरोध कैसे दिए जाते हैं? क्या वे स्मृति में कैश किए गए हैं? – Tulika

0

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

निम्नलिखित विकल्पों की आवश्यकता है जो आप करना चाहते हैं: आर्किटेक्चर: आपको किसी प्रकार के लोड बैलेंसर के साथ 2 साइट सर्वर स्टैक चलाने की आवश्यकता है। (वेब फ्रंट और मिडलवेयर या जो कुछ भी आप कर रहे हैं)

फ़ायरवॉल से एक स्टैक ऑफ लाइन ले जाएं, दूसरी ओर पर लाइव एप्लिकेशन को छोड़ दें ताकि यह सुनिश्चित किया जा सके कि आपके द्वारा नियोजित साइट पर लेन-देन पूरा हो गया है।

अपने तैनाती कार्य करें:

बंद करो वेब साइट/सेवा (AppPool) हटा दें कि वेब सेवा/साइट से संबंधित सभी मौजूदा फ़ाइलों को आपके udpateing उपयोग xcopy सभी फाइलें (या ज़िप निकालने स्थापित करने के लिए लक्षित करने के लिए भी काम करेंगे) वेब साइट/सेवा (AppPool) प्रारंभ नेटवर्क से परीक्षण सुनिश्चित करने के लिए यह सुनिश्चित करता है कि यह परिनियोजन पूर्ण हो गया है।

फ़ायरवॉल लोड संतुलन पर अन्य साइट की पहुंच बंद

और साइट (या sties) को सक्रिय आप पूरा कर लिया है (। इस मौजूदा लेन-देन पूरा करने की अनुमति देगा और अपने नए कोड को लाइव कर देगा।

वहाँ अधिक है आइटम जो आपकी तैनाती में देखा जाना चाहिए, हालांकि यह आपको शुरू करना चाहिए। चीयर्स और भाग्य!

संबंधित मुद्दे

 संबंधित मुद्दे