Създаването на работен пул не дава на извикващия изтеглените страници. Запазете и използвайте стойностите, върнати от подадената работа:

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 тунели също имат значение; настройка за един пул не бива да се описва като една глобална квота за сокети за всеки хост.

Подобни статии