Собирање на секој резултат од паралелни urllib3 прокси барања

Создавањето работен базен не му ги дава на повикувачот преземаните страници. Зачувајте и користете ги вредностите што ги враќа поднесената работа:

from concurrent.futures import ThreadPoolExecutor
import urllib3

manager = urllib3.ProxyManager(
    'http://proxy.example:8080',
    maxsize=4,
    block=True,
)

def fetch(url):
    response = manager.request(
        'GET', url, timeout=urllib3.Timeout(connect=5, read=15),
    )
    return url, response.status, response.data

try:
    with ThreadPoolExecutor(max_workers=4) as workers:
        results = list(workers.map(fetch, urls))
finally:
    manager.clear()

Овој фрагмент претпоставува ограничена листа URL-адреси и вообичаени големини на одговор. За дозволени проверки на јавни URL-адреси без прокси автентикација, кандидат од листата на HTTP прокси може да ја замени примерната HTTP крајна точка на менаџерот. Секој резултат ја вклучува својата URL-адреса за повикувачот да може да го поврзе статусот и телото со точното барање. map враќа резултати по редослед на внес; исклучок во работник се подига кога тој резултат се презема.

Конфигурираниот ProxyManager го поседува базенот на врски за барањата. Со стандардниот режим на однапред вчитан одговор што се користи овде, urllib3 го чита телото и ја враќа врската во својот базен. Верзијата со стриминг би барала експлицитна потрошувачка и ослободување на врската.

maxsize обично ги контролира задржаните повеќекратно употребливи врски, а не тврдо ограничување за секој отворен сокет. block=True го менува соодветното однесување на базенот, така што повикувачите чекаат слободна врска наместо да отвораат дополнителни над ограничувањето на тој базен.

Бројот на работници го ограничува паралелното повикување во овој пример. Со многу одредишта, распоредот на базенот и патеката што се користи за HTTPS тунели исто така се важни; поставка за еден базен не треба да се опишува како една глобална квота на сокети за секој домаќин.