HTTPX PoolTimeout — не тайм-аут з’єднання з проксі

Розпізнайте очікування пулу HTTPX і звільняйте потокові відповіді, перш ніж міняти проксі, який міг не отримати нового запиту.

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(). Закриття непрочитаної відповіді звільняє місткість, але може вимагати відкинути нижнє з’єднання замість повторного використання.

Читайте назву винятку

ConnectTimeout стосується встановлення з’єднання. ReadTimeout — очікування даних відповіді. PoolTimeout — отримання місця для з’єднання. Запис лише «тайм-аут проксі» втрачає відмінність, потрібну для вибору виправлення.

Перш ніж міняти IP кінцевих точок, перевірте відкриті відповіді, паралельні завдання та обмеження з’єднань. Більший пул може підходити виправданому паралельному навантаженню, але не виправить відповіді, які ніколи не закриваються. Він лише дає застосунку більше місткості для зайняття.

Зберігайте клієнт для повторного використання протягом навантаження. Повторне створення клієнта заради видимої працездатності кожного запиту може приховати проблему життєвого циклу й позбавити повторного використання з’єднань.

Схожі статті