HTTPX PoolTimeout என்பது ப்ராக்ஸி இணைப்பு நேர வரம்பல்ல

PoolTimeout என்றால் HTTPX-க்கு அமைத்த காத்திருப்பு நேரத்திற்குள் தொகுப்பிலிருந்து இணைப்பு கிடைக்கவில்லை என்று பொருள். ப்ராக்ஸிக்கான புதிய TCP இணைப்பு நேரம் முடிந்ததற்குச் சான்றல்ல. இரண்டாவது கோரிக்கை இன்னும் உங்கள் செயல்முறைக்குள்ளேயே காத்திருக்கலாம்.

கிளையன்ட் ஒரே இணைப்பை அனுமதித்து முதல் ஸ்ட்ரீமிங் பதில் திறந்திருந்தால் இதை எளிதில் மீண்டும் உருவாக்கலாம். மற்றொரு கோரிக்கையைத் தொடங்குவது அந்த இணைப்பைத் தானாக விடுவிக்காது.

ஸ்ட்ரீமிங் பதிலின் பொறுப்பைத் தெளிவாக்கவும்

import httpx

limits = httpx.Limits(
    max_connections=1,
    max_keepalive_connections=1,
)
timeout = httpx.Timeout(
    connect=5, read=10, write=10, pool=1
)

with httpx.Client(
    proxy="http://203.0.113.10:8080",
    trust_env=False,
    limits=limits,
    timeout=timeout,
) as client:
    with client.stream("GET", "https://example.com/") as response:
        print(response.status_code)
        for chunk in response.iter_bytes():
            print(len(chunk))

    next_response = client.get("https://example.com/")
    print(next_response.status_code)

இயக்குமுன் ஆவண ப்ராக்ஸி முகவரியை மாற்றவும். அடுத்த கோரிக்கை ஸ்ட்ரீம் சூழலிலிருந்து வெளியேறிய பிறகு தொடங்கும். குறியீடு சுழற்சியை இடைநிறுத்தினாலும் விதிவிலக்கு எழுப்பினாலும் வெளியேறும்போது பதில் மூடப்படும்.

client.send(request, stream=True) போன்ற கைமுறை ஸ்ட்ரீமிங்கில் இறுதியில் மூடுவது உங்கள் குறியீட்டின் பொறுப்பு. AsyncClient-இல் தொடர்புடைய கைமுறைத் துப்புரவு response.aclose()-ஐ await செய்வதன் மூலம் செய்யப்படுகிறது. படிக்காத பதிலை மூடுவது கொள்ளளவை விடுவிக்கும்; ஆனால் அடிப்படை இணைப்பை மீண்டும் பயன்படுத்தாமல் கைவிட வேண்டியிருக்கலாம்.

விதிவிலக்கின் பெயரைப் படிக்கவும்

ConnectTimeout இணைப்பை ஏற்படுத்துவது பற்றியது. ReadTimeout பதில் தரவுக்காகக் காத்திருப்பது பற்றியது. PoolTimeout இணைப்பு இடம் கிடைப்பது பற்றியது. «ப்ராக்ஸி நேரம் முடிந்தது» என்று மட்டும் பதிவுசெய்வது சரியான தீர்வைத் தேர்ந்தெடுக்க வேண்டிய வேறுபாட்டை இழக்கிறது.

முனைப்புள்ளி IP-களை மாற்றுமுன் திறந்த பதில்கள், ஒரேநேரப் பணிகள், இணைப்பு வரம்புகள் ஆகியவற்றைப் பாருங்கள். நியாயமான ஒரேநேரச் சுமைக்கு பெரிய தொகுப்பு பொருத்தமாகலாம்; ஆனால் ஒருபோதும் மூடாத பதில்களைச் சரிசெய்யாது. செயலி ஆக்கிரமிக்க அதிக கொள்ளளவு கொடுப்பது மட்டுமே.

முழுப் பணிச்சுமையிலும் கிளையன்டை மீண்டும் பயன்படுத்தக்கூடியதாக வைத்திருங்கள். ஒவ்வொரு கோரிக்கையும் செயல்படுவதுபோல் காட்ட கிளையன்டை மறுபடியும் உருவாக்குவது வாழ்க்கைச் சுழற்சிப் பிரச்சினையை மறைத்து இணைப்பு மறுபயன்பாட்டை இழக்கச் செய்யலாம்.