Pythonプロキシ検査：Future.cancel() がスレッドを動かし続ける理由
保留中の future をキャンセルしても実行中のネットワーク検査が止まらない理由を理解し、宛先の健全性を証明すると主張せずにプロキシの競争を制限する方法を説明します。
1つのワーカーが使用可能なプロキシを見つけます。そのアドレスを返し、他の future に cancel を呼び出して、ネットワーク活動が止まることを期待します。止まらないかもしれません。
Future は callable が始まる前にキャンセルできます。スレッドがすでにリクエストを実行している場合、その Future をキャンセルしてもソケット操作は中断されません。ワーカーには独自の制限付きネットワーク操作とクリーンアップ経路が必要です。
executor の寿命も重要です。ThreadPoolExecutor のコンテキストを離れると、その作業が終わるまで待機します。1つの速い結果を見つけてから複数の遅いワーカーを待つと、呼び出し元の合計遅延は勝者の報告したレイテンシとはまったく違って見えることがあります。
始める前に競争を制限する
- 無制限の公開リストを投入するのではなく、同時検査の数を制限します。無料プロキシリストは検査器の入力に候補を提供し、各エンドポイントのプロトコルはワーカーのために保持されます。
- 各リクエストに適切な接続と読み取りのポリシーを与えます。
- 呼び出し元に全体的な判断予算を与えます。
- 判断より長く生き残ったワーカーの結果を誰が排出または閉じるかを定義します。
Future を短く待つことは、その背後のリクエストを短くすることと同じではありません。同様に、結果を放棄してもすべてのネットワーク資源が直ちに解放されるわけではありません。
最初の成功結果もまた、最初の成功した検査にすぎません。それはスケジューリング、キャッシュされた接続、および特定の検査先に依存する可能性があります。エンドポイントが普遍的に最速であることや、実際のタスクが成功することを証明するものではありません。
多くの場合、最近の観測を持つ小さな保持プールは、ダウンロードのたびにリスト全体と競争するよりも簡単です。実際の操作の結果を使って記録を更新し、失敗に対する制御された回復ポリシーを併用します。事前検査は習慣で毎回タスクを二重化するのではなく、そのコストに見合うべきです。