Kolekti ĉiun rezulton el samtempaj urllib3-prokuraj petoj

Krei laboran naĝejon ne donas al la alvokanto la elŝutitajn paĝojn. Konservu kaj konsumu la valorojn redonitajn de la sendita laboro:

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

Ĉi tiu fragmento supozas limigitan liston de URL-oj kaj ordinarajn respondgrandojn. Por permesitaj publikaj URL-kontroloj sen prokura aŭtentikigo, kandidato el la HTTP-prokura listo povas anstataŭigi la ekzemplan HTTP-finpunkton de la administranto. Ĉiu rezulto inkluzivas sian URL-on por ke la alvokanto povu ligi staton kaj korpon al la ĝusta peto. map redonas rezultojn en eniga ordo; escepto en laboranto leviĝas kiam tiu rezulto estas prenita.

La agordita ProxyManager posedas la konektan naĝejon por la petoj. Kun la ĉi tie uzata implicita antaŭŝovita responda reĝimo, urllib3 legas la korpon kaj redonas la konekton al sia naĝejo. Fluiga versio bezonus eksplicitan konsumon kaj liberigon de la konekto.

maxsize kutime regas retenitajn reuzeblajn konektojn, ne malmolan limon por ĉiu malfermita ingo. block=True ŝanĝas la koncernan naĝejan konduton por ke alvokantoj atendu liberan konekton anstataŭ malfermi pliajn super la limo de tiu naĝejo.

La nombro de laborantoj limigas samtempajn alvokojn en ĉi tiu ekzemplo. Kun multaj cellokoj, ankaŭ gravas la naĝeja aranĝo kaj la vojo uzata por HTTPS-tuneloj; agordo por unu naĝejo ne priskribiĝu kiel unu tutmonda inga kvoto por ĉiu gastiganto.