टप्प्यानुसार कालमर्यादा आणि प्रॉक्सी विनंतीची एकूण अंतिम मुदत

कनेक्शन आणि वाचनाच्या कालमर्यादा ठराविक प्रतीक्षा मर्यादित करतात. त्या संपूर्ण प्रॉक्सी कार्य मर्यादित करतीलच असे नाही; त्यात रांगेतील प्रतीक्षा, DNS, CONNECT, TLS, पुनर्निर्देशन, पुनःप्रयत्न आणि प्रतिसाद वाचन यांचाही समावेश असू शकतो.

कार्याच्या बजेटपासून सुरुवात करा

उपलब्ध असल्यास क्लायंटची नोंदवलेली एकूण अंतिम मुदत किंवा रद्द करण्याची यंत्रणा टप्प्यांच्या मर्यादेसोबत वापरा. HTTPX पूल, कनेक्शन, वाचन आणि लेखन यांच्या प्रतीक्षा वेगळ्या करते. Requests सांगते की त्याची कालमर्यादा पूर्ण डाउनलोडची मर्यादा नाही. curl एकूण हस्तांतरणाची कालमर्यादा देते.

उदाहरणार्थ, वीस सेकंदांचे काम रांगेत दोन सेकंद, मार्ग स्थापित करण्यात तीन आणि अयशस्वी देवघेवीत सहा सेकंद घालवते. त्याच्या पुढील प्रयत्नाकडे सुमारे नऊ सेकंद शिल्लक असतात. प्रत्येक पुनःप्रयत्नाला नवीन वीस सेकंद देणे म्हणजे मूळ बजेट फेकून देणे होय.

गेलेला वेळ मोजण्यासाठी एकदिश घड्याळ वापरा. कार्याचे स्वामित्व असलेल्या स्तरांमधून निरपेक्ष अंतिम मुदत किंवा उर्वरित कालावधी पुढे न्या. आजूबाजूची रद्द करण्याची यंत्रणा आवश्यक व्याप्ती लागू करू शकत नसेल तर ती मर्यादा स्पष्ट करा.

बॉडी आणि स्वच्छता समाविष्ट करा

शीर्षके आल्यानंतर परत येणारी पद्धत बॉडी वाचन त्याच्या अंतिम मुदतीबाहेर ठेवू शकते. बजेट प्रस्थापना, पूर्ण मर्यादित डाउनलोड, की स्वतंत्र जिवंतपणा नियम असलेला दीर्घकालीन प्रवाह यांना व्यापते का ते ठरवा. आधुनिक .NET मधील शीर्षके व बॉडी रद्द करण्याचे उदाहरण दोन्ही टप्प्यांतून एकच टोकन नेते.

पुढील प्रयत्न पूलची क्षमता घेण्यापूर्वी प्रतिसाद बंद करण्यास आणि रद्द करणे पूर्ण करण्यास वेळ ठेवा. अयशस्वी टप्पा आणि गेलेला वेळ नोंदवा; प्रगती करणारी पुनरावृत्ती वाचन निष्क्रियतेच्या मर्यादा पूर्ण करू शकतात, पण एकूण काम खूप लांब चालू शकते.

गेटवेची अपस्ट्रीम अंतिम मुदत त्या गेटवेची असते. त्याने 504 परत केल्यावर न वापरलेले क्लायंट बजेट पूर्ण झालेला प्रयत्न वाढवू शकत नाही. कोणते सेटिंग दुरुस्त करायचे हे ठरवताना प्रत्येक टाइमर त्याच्या मालकाशी जोडलेला ठेवा.