HTTPX PoolTimeout bukan tamat masa sambungan ke proksi

Kenal pasti penantian dalam pool HTTPX dan bebaskan respons penstriman sebelum menggantikan proksi yang mungkin belum menerima permintaan seterusnya.

PoolTimeout bermaksud HTTPX tidak mendapat sambungan daripada pool dalam masa menunggu yang ditetapkan. Ini bukan bukti tamat masa sambungan TCP baharu ke proksi. Permintaan kedua mungkin masih menunggu di dalam proses anda.

Ini mudah dihasilkan semula apabila klien membenarkan satu sambungan dan respons penstriman pertama dibiarkan terbuka. Memulakan permintaan lain tidak membebaskan sambungan itu secara automatik.

Jelaskan tanggungjawab terhadap respons penstriman

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)

Gantikan alamat proksi dokumentasi sebelum menjalankannya. Permintaan seterusnya bermula selepas keluar daripada konteks strim. Keluar daripada konteks menutup respons walaupun kod menghentikan gelung atau menghasilkan pengecualian.

Dalam penstriman manual seperti client.send(request, stream=True), kod anda bertanggungjawab terhadap penutupan akhir. Bagi AsyncClient, pembersihan manual yang sepadan ditunggu dengan response.aclose(). Menutup respons yang belum dibaca membebaskan kapasiti tetapi mungkin memerlukan sambungan asas dibuang dan bukannya digunakan semula.

Baca nama pengecualian

ConnectTimeout berkaitan pembentukan sambungan. ReadTimeout berkaitan menunggu data respons. PoolTimeout berkaitan mendapatkan slot sambungan. Merekod hanya «tamat masa proksi» menghilangkan perbezaan yang diperlukan untuk memilih pembaikan.

Semak respons terbuka, tugas serentak dan had sambungan sebelum menukar IP titik akhir. Pool lebih besar boleh sesuai untuk beban serentak yang sah, tetapi tidak membaiki respons yang tidak pernah ditutup. Ia hanya memberi aplikasi lebih banyak kapasiti untuk diisi.

Kekalkan klien supaya boleh digunakan semula sepanjang beban kerja. Membina semula klien agar setiap permintaan kelihatan berjaya boleh menyembunyikan masalah kitaran hayat dan menghilangkan penggunaan semula sambungan.

Artikel berkaitan