चरणगत समयसीमा र प्रोक्सी अनुरोधको समग्र अन्तिम समय

जडान र पढाइका समयसीमाहरूले निश्चित प्रतीक्षाहरू सीमित गर्छन्। तिनले सम्पूर्ण प्रोक्सी कार्य अनिवार्य रूपमा सीमित गर्दैनन्, जसमा पङ्क्तिमा प्रतीक्षा, DNS, CONNECT, TLS, पुनर्निर्देशन, पुनः प्रयास र प्रतिक्रिया पढ्ने कार्य पनि समावेश हुन सक्छ।

कार्यको बजेटबाट सुरु गर्नुहोस्

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

उदाहरणका लागि, बीस सेकेन्डको कामले पङ्क्तिमा दुई सेकेन्ड, मार्ग स्थापनामा तीन र असफल आदानप्रदानमा छ सेकेन्ड बिताउँछ। यसको अर्को प्रयाससँग करिब नौ सेकेन्ड बाँकी हुन्छ। हरेक पुनः प्रयासलाई नयाँ बीस सेकेन्ड दिनु मूल बजेट फ्याँक्नु हो।

बितेको समय हिसाब गर्न एकदिश घडी प्रयोग गर्नुहोस्। कार्यको स्वामित्व भएका तहहरूबाट निरपेक्ष अन्तिम समय वा बाँकी अवधि लैजानुहोस्। वरपरको रद्द गर्ने संयन्त्रले आवश्यक दायरा लागू गर्न सक्दैन भने त्यो सीमा स्पष्ट पार्नुहोस्।

बडी र सफाइ समावेश गर्नुहोस्

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

अर्को प्रयासले पूलको क्षमता लिनुअघि प्रतिक्रिया बन्द गर्न र रद्द गर्ने काम पूरा गर्न समय छोड्नुहोस्। असफल चरण र बितेको समय अभिलेख गर्नुहोस्; प्रगति गर्ने दोहोरिएका पढाइले निष्क्रियता सीमा पूरा गर्न सक्छन्, तर कुल काम धेरै लामो हुन्छ।

गेटवेको अपस्ट्रिम अन्तिम समय त्यही गेटवेको हो। यसले 504 फर्काएपछि प्रयोग नगरिएको ग्राहक बजेटले पूरा भइसकेको प्रयास लम्ब्याउन सक्दैन। कुन सेटिङ सुधार्नुपर्छ भन्ने निर्णय गर्दा हरेक टाइमरलाई यसको मालिकसँग जोडिराख्नुहोस्।