તબક્કા સમયમર્યાદા અને પ્રોક્સી વિનંતીની એકંદર અંતિમ મુદત

કનેક્શન અને વાંચન સમયમર્યાદા ચોક્કસ રાહ જોવાને મર્યાદિત કરે છે. તે જરૂરી નથી કે આખી પ્રોક્સી કામગીરીને મર્યાદિત કરે, જેમાં કતારમાં રાહ, DNS, CONNECT, TLS, રીડાયરેક્ટ, ફરી પ્રયાસો અને પ્રતિસાદ વાંચવો પણ સામેલ હોઈ શકે.

કામગીરીના બજેટથી શરૂ કરો

ક્લાયન્ટની દસ્તાવેજીકૃત એકંદર અંતિમ મુદત અથવા રદ કરવાની પદ્ધતિ જ્યાં ઉપલબ્ધ હોય ત્યાં તબક્કા મર્યાદાઓ સાથે વાપરો. HTTPX પૂલ, કનેક્શન, વાંચન અને લેખનની રાહ અલગ કરે છે. Requests જણાવે છે કે તેની સમયમર્યાદા સંપૂર્ણ ડાઉનલોડની મર્યાદા નથી. curl કુલ ટ્રાન્સફરની સમયમર્યાદા આપે છે.

ઉદાહરણ તરીકે, વીસ સેકન્ડનું કામ બે સેકન્ડ કતારમાં, ત્રણ તેનો માર્ગ સ્થાપવામાં અને છ નિષ્ફળ આદાનપ્રદાનમાં વિતાવે છે. તેના આગલા પ્રયાસ પાસે લગભગ નવ સેકન્ડ બાકી છે. દરેક ફરી પ્રયાસને નવી વીસ સેકન્ડ આપવાથી મૂળ બજેટ ફેંકાઈ જાય.

વીતેલા સમયના હિસાબ માટે એકદિશ ઘડિયાળ વાપરો. કામ ધરાવતા સ્તરોમાંથી સંપૂર્ણ અંતિમ મુદત અથવા બાકી સમયગાળો લઈ જાઓ. જો આસપાસની રદ કરવાની પદ્ધતિ જરૂરી વ્યાપ્તિ લાગુ કરી શકતી ન હોય, તો તે મર્યાદા સ્પષ્ટ કરો.

બોડી અને સફાઈ સામેલ કરો

હેડર પછી પાછી આવતી પદ્ધતિ બોડી વાંચવાને તેની અંતિમ મુદતની બહાર મૂકી શકે છે. બજેટ સ્થાપના, સંપૂર્ણ મર્યાદિત ડાઉનલોડ કે અલગ જીવંતતા નિયમોવાળા લાંબા સ્ટ્રીમને આવરે છે કે નહીં તે નક્કી કરો. આધુનિક .NET માં હેડર અને બોડી રદ કરવાનું ઉદાહરણ બંને તબક્કામાં એક જ ટોકન લઈ જાય છે.

આગલો પ્રયાસ પૂલની ક્ષમતા લે તે પહેલાં પ્રતિસાદ બંધ કરવા અને રદ પૂર્ણ કરવા સમય રાખો. નિષ્ફળ તબક્કો અને વીતેલો સમય નોંધો; પ્રગતિ કરતા પુનરાવર્તિત વાંચન નિષ્ક્રિયતા મર્યાદા સંતોષી શકે છે જ્યારે કુલ કામ ઘણું લાંબું ચાલે છે.

ગેટવેની અપસ્ટ્રીમ અંતિમ મુદત તે ગેટવેની છે. તે 504 પરત કરે પછી, વણવપરાયેલ ક્લાયન્ટ બજેટ પૂર્ણ થયેલા પ્રયાસને લંબાવી શકતું નથી. કઈ સેટિંગ સુધારવી તે નક્કી કરતી વખતે દરેક ટાઈમરને તેના માલિક સાથે જોડેલું રાખો.