Una consulta bloqueante al pool de proxies puede atascar Scrapy
Mantén una llamada síncrona a la API del pool de proxies fuera de la ruta del bucle de eventos de Scrapy y da al descubrimiento de endpoints su propia política de fallos.
El rastreador tiene configuradas suficientes peticiones concurrentes. Aun así se detiene cada vez que pide otra dirección al pool de proxies. Añadir más proxies no cambia esa pausa.
Un patrón de middleware habitual llama a requests.get(pool_url) dentro de process_request(). Es una operación de red síncrona en una ruta que debería cooperar con el motor asíncrono de Scrapy. Mientras la llamada espera, puede retener trabajo no relacionado en el mismo hilo del bucle de eventos.
Hay dos peticiones en el trabajo
Una petición obtiene un endpoint del servicio del pool. La otra usa ese endpoint para contactar con el destino. Mídelas y repórtalas por separado. Una API de pool lenta puede hacer que cada proxy elegido parezca lento antes de que la aplicación se haya conectado siquiera a él.
Usa una integración de descubrimiento asíncrona compatible con la versión de Scrapy instalada, u obtén y refresca un conjunto local y acotado de endpoints fuera de la ruta crítica de cada petición. Si hay que descargar trabajo bloqueante, da a ese ejecutor sus propios límites y gestión de tiempos de espera; una cola ilimitada solo traslada el retraso.
No lances automáticamente otra llamada de descubrimiento para cada petición. Una caché de corta duración o un lote arrendado pueden reducir la dependencia del servicio del pool, siempre que su vida útil encaje con la política real de endpoints del servicio.
Define qué significa una consulta fallida
Una respuesta vacía o fallida del pool no debería eliminar en silencio los metadatos del proxy y permitir una petición directa. Elige un resultado explícito: esperar dentro del presupuesto de la tarea, fallar o usar un endpoint en caché aprobado.
Mantén también despejada la ruta propia de la API del pool. Si es un servicio interno, enviar su nombre de host privado a través del mismísimo proxy que ayuda a seleccionar puede crear una dependencia circular.
Una vez que el descubrimiento funcione sin bloquear trabajo no relacionado, examina la transacción normal de proxy. Son reparaciones distintas, y su temporización merece campos distintos en el registro.