ブロックするプロキシプール検索は Scrapy を停止させ得る

クローラーには十分な数の同時リクエストが設定されている。それでもプロキシプールに別のアドレスを問い合わせるたびに停止する。プロキシを増やしてもその停止は変わらない。

よくあるミドルウェアのパターンは、requests.get(pool_url) を process_request() の中で呼び出す。これは Scrapy の非同期エンジンと協調すべき経路での同期的なネットワーク操作である。呼び出しが待っている間、同じイベントループスレッド上の無関係な処理を妨げることがある。

ジョブには二つのリクエストがある

一方のリクエストはプールサービスからエンドポイントを取得する。もう一方はそのエンドポイントを使って宛先に接続する。両方を別々に計測して報告すること。遅いプール API は、アプリケーションがまだ接続していなくても、選んだプロキシをすべて遅く見せてしまう。

インストール済みの Scrapy バージョンが対応する非同期の探索連携を使うか、リクエストごとのクリティカルパスの外で、上限付きのローカルなエンドポイント集合を取得して更新すること。ブロックする処理を退避させる必要があるなら、その実行器に独自の上限とタイムアウト処理を与えること。無制限のキューは遅延の場所を移すだけである。

リクエストごとに自動でもう一度探索呼び出しを出してはならない。短命のキャッシュやリースしたバッチは、その寿命がサービスの実際のエンドポイントポリシーに合う限り、プールサービスへの依存を減らせる。

失敗した検索の意味を定義する

空または失敗したプール応答が、プロキシのメタデータを黙って削除して直接リクエストを許可してはならない。明示的な結果を選ぶこと。タスクの予算内で待つ、失敗する、承認済みのキャッシュ済みエンドポイントを使う、のいずれかである。

プール API 自身の経路も空けておくこと。内部サービスなら、選択を助けるそのプロキシ自体を通してプライベートなホスト名を送ると、循環依存を作りかねない。

探索が無関係な処理を妨げずに動くようになったら、通常のプロキシ処理を調べること。それらは別の修理であり、その計測にはログの別フィールドがふさわしい。