フェーズごとのタイムアウトとプロキシリクエスト全体の期限

接続タイムアウトと読み取りタイムアウトは、特定の待ち時間を制限します。しかしプロキシ処理全体を必ず制限するわけではありません。処理にはキュー待ち、DNS、CONNECT、TLS、リダイレクト、リトライ、レスポンスの消費も含まれ得ます。

処理の予算から始める

利用可能であれば、クライアントが文書化した全体期限やキャンセルの仕組みを、フェーズ制限と併用します。HTTPX はプール、接続、読み取り、書き込みの待機を分けています。Requests は自身のタイムアウトが完全なダウンロードの制限ではないと明記しています。curl は転送全体のタイムアウトを提供します。

たとえば、二十秒のジョブがキューで二秒、経路確立に三秒、失敗したやり取りに六秒を使ったとします。次の試行に残るのはおよそ九秒です。再試行ごとに新たな二十秒を与えると、元の予算を捨てることになります。

経過時間の計測には単調時計を使います。絶対的な期限または残り時間を、その処理を担う層へ引き継いでください。周囲のキャンセルの仕組みが必要な範囲を強制できない場合は、その制限を明示します。

ボディと後片付けを含める

ヘッダー後に戻るメソッドでは、ボディの読み取りがその期限の外に残ることがあります。予算が確立までか、有限のダウンロード全体か、別の生存判定を持つ長寿命ストリームかを決めてください。ヘッダーとボディで一つのトークンを引き回す現代的な .NET の例は、両段階を通じて同じトークンを運びます。

次の試行がプール容量を取る前に、レスポンスを閉じキャンセルを完了する時間を残します。失敗した段階と経過時間を記録してください。進行のある繰り返し読み取りは無通信の制限を満たしても、処理全体が長すぎることがあります。

ゲートウェイの上流向け期限はそのゲートウェイのものです。504 を返した後では、未使用のクライアント予算で完了済みの試行を延長することはできません。どの設定を直すべきかを決めるときは、各タイマーをその所有者に結び付けたままにします。