API Timeout: कनेक्शन ड्रॉप्स का निदान और सुरक्षित पुनः प्रयास का निर्णय
LLM API timeout की सही परत खोजने, केवल जिम्मेदार सीमा बदलने और दो नियंत्रित परीक्षणों से सुधार सत्यापित करने की व्यावहारिक गाइड।
विषय-सूची
API Timeout: कनेक्शन ड्रॉप्स का निदान और सुरक्षित पुनः प्रयास का निर्णय
API Timeout का अर्थ है कि अनुरोध की किसी परत ने प्रतीक्षा करना बंद कर दिया। क्लाइंट कनेक्ट नहीं कर पाया हो सकता है, प्रॉक्सी ने निष्क्रिय स्ट्रीम बंद की हो सकती है, एप्लिकेशन की कुल समय-सीमा समाप्त हुई हो सकती है, या गेटवे को upstream मॉडल से समय पर उत्तर नहीं मिला हो सकता है। केवल यह संदेश मॉडल के बंद होने का प्रमाण नहीं है।
पुनः प्रयास से पहले exception class, उपलब्ध HTTP status और body, कुल समय, request ID और प्राप्त chunks दर्ज करें। इसके बाद केवल उसी परत की सीमा बदलें जिसकी विफलता प्रमाणित हुई है। सभी timeouts बढ़ाने से कारण छिप जाता है और अज्ञात परिणाम वाली कार्रवाई दोहर सकती है।
यदि अनुरोध BetterToken से गया था, तो retry से पहले Dashboard खोलें और समय, मॉडल, status तथा Token उपयोग मिलाएँ। इससे API तक पहुँचा अनुरोध gateway से पहले हुई विफलता से तुरंत अलग हो जाता है।
एक timeout के कई संभावित कारण
एप्लिकेशन / SDK
→ DNS और TCP/TLS
→ कॉर्पोरेट या reverse proxy
→ API gateway
→ upstream मॉडल
→ क्लाइंट तक streaming उत्तरConnect timeout DNS, TCP और TLS कनेक्शन बनने तक लागू होता है। Read या stream-idle timeout तब होता है जब क्लाइंट की सीमा के भीतर अगला chunk नहीं आता। Pool timeout खाली क्लाइंट कनेक्शन की प्रतीक्षा है। कुल deadline पूरी व्यावसायिक कार्रवाई को सीमित करती है, जबकि upstream timeout gateway या provider की अलग सीमा है। एक सीमा बढ़ाने से दूसरी सीमाएँ नहीं बदलतीं।
विफलता की परत कैसे खोजें
| संकेत | संभावित परत | अगली जाँच |
|---|---|---|
httpx.ConnectTimeout, HTTP उत्तर नहीं | DNS, TCP या TLS | उसी runtime से परीक्षण करें; DNS, CA, proxy और firewall तुलना करें |
chunks से पहले या बीच में httpx.ReadTimeout | क्लाइंट read/idle या बीच का proxy | पहले byte और chunks के बीच का समय मापें; proxy idle सीमा जाँचें |
| HTTP status और error body मिले | gateway या upstream | status, body और request ID रखें; provider के error contract का पालन करें |
httpx.PoolTimeout | क्लाइंट pool | concurrency और pool occupancy मापें; saturation प्रमाणित होने पर ही सीमा बदलें |
| हर बार समान कुल समय पर रद्द | एप्लिकेशन, job runner या reverse proxy | deadline के मालिक को पहचानें और नीचे की सभी सीमाओं से तुलना करें |
क्रम यह रखें: पहले संकेत सुरक्षित करें, फिर उसी host या container से दोहराएँ, हर बीच के proxy की जाँच करें और उसके बाद gateway या upstream पर जाएँ। मॉडल, prompt, network, endpoint और proxy को स्थिर रखें; हर परीक्षण में केवल एक चर बदलें।
HTTPX connect, read, write और pool timeouts को अलग-अलग परिभाषित करता है। कोई एक संख्या हर सिस्टम के लिए सही नहीं है। वास्तविक मान मापी गई request phases, chunks के बीच अपेक्षित विराम और कुल deadline से तय करें।
timeout, output या retry कब बदलें
- Connect timeout केवल तब बदलें जब DNS/TCP/TLS का धीमा बनना प्रमाणित हो।
- Read या idle timeout तभी बदलें जब कनेक्शन बन चुका हो और chunks के बीच प्रमाणित सीमा समाप्त हो।
- कुल deadline तभी बढ़ाएँ जब व्यावसायिक कार्रवाई अधिक समय ले सकती हो और नीचे की परतें सही हों।
- यदि केवल नियंत्रित लंबा परीक्षण विफल हो तो output कम या विभाजित करें; बिना माप के इसे कारण न मानें।
429और context overflow को अलग संकेत की तरह संभालें; वे connect timeout नहीं हैं।
अज्ञात कार्रवाई को दोहराए बिना सुरक्षित retry
अनुरोध भेजने के बाद timeout को पहले अज्ञात परिणाम मानें। स्थानीय task ID logs जोड़ने में मदद करती है, पर दूसरी server operation नहीं रोकती। स्वचालित retry तभी करें जब server का दस्तावेज idempotency या status lookup देता हो और बाहरी प्रमाण दिखाता हो कि पहला अनुरोध स्वीकार नहीं हुआ।
न्यूनतम सूची:
- Request ID, status/body, timestamps और प्राप्त chunks सुरक्षित रखें।
- गैर-idempotent कार्रवाई दोहराने से पहले वास्तविक परिणाम जाँचें।
- आंशिक stream को स्वतः फिर न भेजें; दूसरी generation और अतिरिक्त उपयोग हो सकता है।
- प्रयासों की संख्या और कुल deadline दोनों सीमित करें; SDK, proxy और application retries को साथ गिनें।
- SSE iteration के दौरान आने वाली त्रुटि भी पकड़ें, केवल response object बनाते समय की नहीं।
दो परीक्षण सुधार की पुष्टि करते हैं
- छोटा नियंत्रण अनुरोध: छोटा उत्तर माँगें और status, पहले byte का समय, कुल अवधि, request ID और stream completion दर्ज करें। विफल होने पर पहले network, authentication और endpoint जाँचें।
- नियंत्रित लंबा अनुरोध: छोटे परीक्षण के सफल होने के बाद केवल अपेक्षित output बढ़ाएँ या मूल workload लौटाएँ। मॉडल, endpoint, network और proxy न बदलें। केवल यह परीक्षण विफल हो तो read/idle timeout, कुल deadline और बीच की सीमाओं की तुलना करें।
सुधार तभी प्रमाणित है जब छोटा परीक्षण और मूल परिस्थिति का एक पुनः परीक्षण अपेक्षित परिणाम के साथ और बिना अस्पष्ट duplicate के पूरा हो। यदि अनुरोध BetterToken तक पहुँचा, तो Dashboard में समय, मॉडल, status और Token उपयोग मिलाएँ, फिर endpoint contract की जाँच करें।
