Requests が pool_maxsize より多くの接続を開く理由
上限付きのプールには pool_block を使い、上限がプロキシ経由のすべての通信を対象にする必要がある場合はアプリケーション側の予算を追加します。
既定の pool_block=False では、pool_maxsize が制限するのはプール内に保持される接続であり、同時接続のすべてではありません。Requests は追加の接続を作成し、その後で破棄することがあります。
既存のセッションの HTTPS リクエストが使う上限付きプールの場合:
from requests.adapters import HTTPAdapter
adapter = HTTPAdapter(
pool_connections=10,
pool_maxsize=4,
pool_block=True,
)
session.mount("https://", adapter)マウントは HTTPS の宛先 URL を選択します。HTTP リクエストは http:// にマウントされたアダプターを使います。
| 入力 | 制御する内容 |
|---|---|
| pool_connections | マネージャーがキャッシュするプール数 |
| pool_maxsize | 1 つのプール内の接続数 |
| pool_block=True | 追加の接続を作らずにプールの接続を待つ |
Requests はプロキシ URL ごとにプロキシマネージャーもキャッシュします。これらの値は、入れ替わるプロキシと宛先の一覧全体に対する単一の総量上限にはなりません。すべての処理を 1 つの中間者経由にする必要がある場合は、アプリケーション側で同時実行の予算を設けてください。
ブロックする場合、応答の解放が不可欠です。本文を読み切るか、ストリーミング応答を閉じることで、待機中の処理を進められます。ここに示す構成では、Requests のアダプターはこのプール待ちに別個のタイムアウトを提供しません。