Bakit nagbubukas ang Requests ng mas maraming koneksyon kaysa pool_maxsize
Gumamit ng pool_block para sa limitadong pool, at magdagdag ng badyet sa antas ng aplikasyon kapag kailangang sakupin ng limitasyon ang lahat ng trapiko sa isang proxy.
Sa default na pool_block=False, nililimitahan ng pool_maxsize ang mga koneksyong pinapanatili sa isang pool, hindi ang bawat sabay-sabay na koneksyon. Maaaring gumawa ang Requests ng dagdag at itapon ang mga ito pagkatapos.
Para sa limitadong pool na ginagamit ng mga kahilingang HTTPS ng umiiral na sesyon:
from requests.adapters import HTTPAdapter
adapter = HTTPAdapter(
pool_connections=10,
pool_maxsize=4,
pool_block=True,
)
session.mount("https://", adapter)Pinipili ng mount ang mga URL ng destinasyong HTTPS. Ginagamit ng mga kahilingang HTTP ang adapter na naka-mount sa ilalim ng http://.
| Input | Ano ang kinokontrol nito |
|---|---|
| pool_connections | Ilan ang mga pool na naka-cache sa manager |
| pool_maxsize | Mga koneksyon sa loob ng isang pool |
| pool_block=True | Maghintay ng koneksyon sa pool sa halip na gumawa ng dagdag |
Naka-cache din ang Requests ng mga proxy manager ayon sa URL ng proxy. Ang mga halagang ito ay hindi bumubuo ng isang kabuuang takip sa isang umiikot na listahan ng mga proxy at destinasyon. Gumamit ng badyet sa sabay-sabay na paggana sa antas ng aplikasyon kung ang pangangailangan ay dumaan ang lahat ng gawain sa isang tagapamagitan.
Ginagawang mahalaga ng pag-block ang pagpapalaya ng mga tugon: ubusin ang mga katawan o isara ang mga streaming na tugon upang makapagpatuloy ang naghihintay na gawain. Hindi nagbibigay ang adapter ng Requests ng hiwalay na timeout para sa paghihintay na ito sa pool sa inihandang setup.