ফেজ টাইমআউট এবং সামগ্রিক প্রক্সি অনুরোধের সময়সীমা

সংযোগ ও পড়ার টাইমআউট নির্দিষ্ট অপেক্ষা সীমিত করে। এগুলো পুরো একটি প্রক্সি অপারেশন সীমিত করে না; সেই অপারেশনে অপেক্ষমাণ সারি, DNS, CONNECT, TLS, পুনর্নির্দেশ, পুনরায় চেষ্টা এবং প্রতিক্রিয়া পড়াও থাকতে পারে।

অপারেশনের বাজেট দিয়ে শুরু করুন

ক্লায়েন্টের নথিভুক্ত সামগ্রিক সময়সীমা বা বাতিল করার পদ্ধতি যেখানে আছে সেখানে ফেজ সীমার সাথে ব্যবহার করুন। HTTPX পুল, সংযোগ, পড়া ও লেখার অপেক্ষা আলাদা করে। Requests জানায় যে এর টাইমআউট সম্পূর্ণ ডাউনলোডের সীমা নয়। curl মোট স্থানান্তরের টাইমআউট দেয়।

উদাহরণস্বরূপ, বিশ সেকেন্ডের একটি কাজ সারিতে দুই সেকেন্ড, পথ স্থাপনে তিন সেকেন্ড এবং ব্যর্থ বিনিময়ে ছয় সেকেন্ড ব্যয় করে। এর পরবর্তী চেষ্টার প্রায় নয় সেকেন্ড বাকি থাকে। প্রতিটি পুনরায় চেষ্টাকে নতুন বিশ সেকেন্ড দিলে মূল বাজেট বাতিল হয়ে যাবে।

অতিবাহিত সময় হিসাবের জন্য একমুখী ঘড়ি ব্যবহার করুন। কাজের মালিক স্তরগুলোর মধ্যে সম্পূর্ণ সময়সীমা বা অবশিষ্ট সময় বহন করুন। আশপাশের বাতিল পদ্ধতি যদি প্রয়োজনীয় পরিধি কার্যকর করতে না পারে, সেই সীমাবদ্ধতা স্পষ্ট করুন।

বডি ও পরিষ্কার করা অন্তর্ভুক্ত করুন

হেডারের পরে ফেরা কোনো মেথড বডি পড়াকে তার সময়সীমার বাইরে রেখে যেতে পারে। বাজেটটি সংযোগ স্থাপন, সম্পূর্ণ সসীম ডাউনলোড, নাকি পৃথক জীবনী কাঠামোসহ দীর্ঘস্থায়ী স্ট্রিম কভার করে তা ঠিক করুন। আধুনিক .NET-এ একই টোকেন দিয়ে হেডার ও বডি বাতিলের উদাহরণ উভয় ধাপে একটি টোকেন বহন করে।

পরবর্তী চেষ্টা পুলের সক্ষমতা নেওয়ার আগে প্রতিক্রিয়া বন্ধ করা ও বাতিল সম্পূর্ণ করার সময় রাখুন। ব্যর্থ ধাপ ও অতিবাহিত সময় লিপিবদ্ধ করুন; অগ্রগতি করা পুনরাবৃত্তি পড়া নিষ্ক্রিয়তার সীমা মেটাতে পারে, অথচ সামগ্রিক কাজ চলতে থাকে অনেক বেশি সময় ধরে।

গেটওয়ের উর্ধ্বমুখী সময়সীমা সেই গেটওয়েরই। এটি 504 ফেরানোর পর অব্যবহৃত ক্লায়েন্ট বাজেট সম্পূর্ণ হওয়া চেষ্টাকে বাড়াতে পারে না। কোন সেটিং ঠিক করতে হবে তা ঠিক করার সময় প্রতিটি টাইমারকে তার মালিকের সাথে রাখুন।