Squid retry_on_error: स्थिति कोड और वैकल्पिक मार्ग

Squid में retry_on_error नाम का एक विकल्प है, लेकिन नाम उसके उपयोगी अर्थ से विस्तृत है। इसका मतलब यह नहीं है कि हर विफल अनुरोध तब तक अनिश्चित काल तक दोहराया जाएगा जब तक पृष्ठ काम करने न लगे।

इस निर्देश का समर्थन करने वाले संस्करणों में यह डिफ़ॉल्ट रूप से बंद है। प्रलेखित पुनरावृत्ति सूची 403, 500, 501, 502, 503 और 504 है, और यह अनुरोध को किसी अन्य कार्यशील गंतव्य से आज़माता है। यह वैकल्पिक फ़ॉरवर्डिंग पथों वाले पदानुक्रम में विशेष रूप से प्रासंगिक है। यह केवल उसी सॉकेट से उसी सर्वर तक समयबद्ध पुनःप्रयास नहीं है।

पहले विफलता का नाम लें

प्रॉक्सी से कनेक्ट करते समय इनकार, प्रॉक्सी प्रमाणीकरण विफलता, मूल से HTTP त्रुटि, और डिलीवरी शुरू होने के बाद कटा हुआ उत्तर—ये सभी एक जैसा पुनःप्रयास अवसर नहीं देते। एक सेटिंग चारों को एक जैसा संभालेगी, ऐसी अपेक्षा न रखें।

निजी निकास के लिए यह भी तय करें कि वैकल्पिक मार्ग स्वीकार्य है या नहीं। किसी अन्य parent का दूसरा सार्वजनिक स्रोत पता, प्रमाणीकरण नीति या नेटवर्क स्थान हो सकता है। उस विकल्प से सफलता उस कारण का उल्लंघन कर सकती है जिसके लिए पहला parent चुना गया था।

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

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

रुक-रुककर होने वाली विफलताओं की जाँच करते समय स्थिति, चुना गया parent या गंतव्य और प्रयासों का क्रम दर्ज करें। अन्यथा पुनरावृत्तियाँ बार-बार होने वाली रूटिंग समस्या को सामान्य रूप से धीमी वेबसाइट जैसी दिखा सकती हैं और वह पथ छिपा सकती हैं जो वास्तव में विफल हुआ।