블로킹 프록시 풀 조회가 Scrapy를 멈추게 할 수 있다

크롤러에는 충분한 동시 요청이 설정되어 있다. 그래도 프록시 풀에 다른 주소를 요청할 때마다 멈춘다. 프록시를 더 추가해도 그 멈춤은 달라지지 않는다.

흔한 미들웨어 패턴은 requests.get(pool_url) 를 process_request() 안에서 호출한다. 이것은 Scrapy의 비동기 엔진과 협력해야 하는 경로에서 수행되는 동기 네트워크 작업이다. 호출이 대기하는 동안 같은 이벤트 루프 스레드의 무관한 작업을 붙잡을 수 있다.

작업에는 두 개의 요청이 있다

하나는 풀 서비스에서 엔드포인트를 얻는다. 다른 하나는 그 엔드포인트로 목적지에 접속한다. 둘을 따로 측정해 보고하라. 느린 풀 API는 애플리케이션이 아직 연결하기도 전에 선택된 모든 프록시를 느리게 보이게 할 수 있다.

설치된 Scrapy 버전이 지원하는 비동기 탐색 통합을 사용하거나, 요청별 핵심 경로 밖에서 제한된 로컬 엔드포인트 집합을 확보해 갱신하라. 블로킹 작업을 옮겨야 한다면 그 실행기에 자체 한도와 타임아웃 처리를 주어라. 무제한 큐는 지연의 위치만 옮긴다.

요청마다 자동으로 또 다른 탐색 호출을 내보내지 마라. 수명이 짧은 캐시나 임대한 배치는 서비스의 실제 엔드포인트 정책에 수명이 맞는다면 풀 서비스 의존을 줄여 줄 수 있다.

실패한 조회의 의미를 정의하라

비었거나 실패한 풀 응답이 프록시 메타데이터를 조용히 제거하고 직접 요청을 허용해서는 안 된다. 명시적인 결과를 고르라. 작업 예산 안에서 기다리거나, 실패하거나, 승인된 캐시 엔드포인트를 사용하는 것이다.

풀 API 자체의 경로도 비워 두라. 내부 서비스라면 자신이 선택을 돕는 바로 그 프록시를 통해 사설 호스트 이름을 보내면 순환 의존이 생길 수 있다.

탐색이 무관한 작업을 막지 않고 동작하게 되면, 평범한 프록시 트랜잭션을 살펴보라. 그것은 별개의 수리이며, 그 시간 측정은 로그에서 별도 필드를 받을 만하다.