Å opprette en arbeiderpool gir ikke den som kaller, de nedlastede sidene. Ta vare på og konsumer verdiene som arbeidet som ble sendt inn, returnerer:

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()

Dette utsnittet forutsetter en begrenset liste over URL-er og vanlige svardimensjoner. For tillatte offentlige URL-kontroller uten proxyautentisering kan en kandidat fra HTTP-proxylisten erstatte eksempel-HTTP-endepunktet til behandleren. Hvert resultat inneholder URL-en sin, slik at den som kaller, kan knytte status og innhold til riktig forespørsel. map returnerer resultater i inndata-rekkefølge; et unntak i en arbeider kastes når det resultatet hentes.

Den konfigurerte ProxyManager eier tilkoblingspoolen for forespørslene. Med standardmodusen for forhåndslastede svar som brukes her, leser urllib3 innholdet og returnerer tilkoblingen til poolen sin. En strømmende versjon vil trenge eksplisitt konsum og frigjøring av tilkoblingen.

maxsize styrer vanligvis beholdte gjenbrukbare tilkoblinger, ikke en hard grense på hver åpne socket. block=True endrer den relevante poolatferden slik at den som kaller, venter på en ledig tilkobling i stedet for å åpne flere utover grensen til den poolen.

Antall arbeidere begrenser samtidige kall i dette eksempelet. Med mange destinasjoner er også pooloppsettet og ruten som brukes for HTTPS-tunneler, viktige; en innstilling per pool bør ikke beskrives som en global socket-kvote for hver vert.

Relaterte artikler