चरण-वार समय-सीमाएँ और प्रॉक्सी अनुरोध की समग्र समय-सीमा

कनेक्शन और पढ़ने की समय-सीमाएँ कुछ निश्चित प्रतीक्षाओं को सीमित करती हैं। वे ज़रूरी नहीं कि पूरे प्रॉक्सी संचालन को सीमित करें, जिसमें कतार में प्रतीक्षा, DNS, CONNECT, TLS, रीडायरेक्ट, पुनः प्रयास और प्रतिक्रिया पढ़ना भी शामिल हो सकता है।

संचालन के बजट से शुरू करें

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

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

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

बॉडी और सफ़ाई को शामिल करें

हेडर के बाद लौटने वाली विधि बॉडी पढ़ने को अपनी समय-सीमा से बाहर छोड़ सकती है। तय करें कि बजट स्थापना, पूर्ण सीमित डाउनलोड, या अलग जीवंतता नियमों वाली दीर्घकालिक स्ट्रीम को कवर करता है। आधुनिक .NET में हेडर और बॉडी रद्द करने का उदाहरण दोनों चरणों में एक ही टोकन ले जाता है।

अगला प्रयास पूल की क्षमता लेने से पहले प्रतिक्रियाएँ बंद करने और रद्द करना पूरा करने के लिए समय छोड़ें। असफल चरण और बीता समय दर्ज करें; प्रगति करती बार-बार की पढ़ाई निष्क्रियता की सीमाएँ संतुष्ट कर सकती है जबकि कुल कार्य बहुत लंबा चल रहा है।

गेटवे की अपस्ट्रीम समय-सीमा उसी गेटवे की है। 504 लौटाने के बाद, अप्रयुक्त क्लाइंट बजट पूर्ण हुए प्रयास को नहीं बढ़ा सकता। कौन-सी सेटिंग सुधारनी है यह तय करते समय हर टाइमर को उसके स्वामी से जोड़े रखें।