Waarom Requests meer verbindingen opent dan pool_maxsize
Gebruik pool_block voor een begrensde pool en voeg een budget op applicatieniveau toe wanneer de limiet al het verkeer via een proxy moet dekken.
Met de standaard pool_block=False beperkt pool_maxsize de verbindingen die in een pool worden bewaard, niet elke gelijktijdige verbinding. Requests kan extra's aanmaken en die daarna weggooien.
Voor een begrensde pool die de HTTPS-verzoeken van een bestaande sessie gebruiken:
from requests.adapters import HTTPAdapter
adapter = HTTPAdapter(
pool_connections=10,
pool_maxsize=4,
pool_block=True,
)
session.mount("https://", adapter)De mount kiest HTTPS-bestemmings-URL's. HTTP-verzoeken gebruiken de adapter die onder http:// is gemount.
| Invoer | Wat het regelt |
|---|---|
| pool_connections | Hoeveel pools de beheerder cachet |
| pool_maxsize | Verbindingen binnen één pool |
| pool_block=True | Wachten op een poolverbinding in plaats van een extra aanmaken |
Requests cachet ook proxybeheerders per proxy-URL. Deze waarden vormen geen enkele totale limiet over een roterende lijst van proxies en bestemmingen. Gebruik een budget voor gelijktijdigheid op applicatieniveau als de eis is dat al het werk via één tussenpersoon gaat.
Blokkeren maakt het vrijgeven van reacties essentieel: verbruik lichamen of sluit streaming-reacties zodat wachtend werk verder kan. De adapter van Requests biedt in de getoonde opzet geen aparte time-out voor dit wachten op de pool.