워커 하나가 사용 가능한 프록시를 찾습니다. 주소를 반환하고 다른 future에 cancel을 호출한 뒤 네트워크 활동이 멈추기를 기대합니다. 멈추지 않을 수 있습니다.

Future는 callable이 시작되기 전에 취소할 수 있습니다. 스레드가 이미 요청을 실행 중이라면 Future를 취소해도 해당 소켓 작업은 중단되지 않습니다. 워커에는 자체적인 제한된 네트워크 작업과 정리 경로가 필요합니다.

executor의 수명도 중요합니다. ThreadPoolExecutor 컨텍스트를 벗어나면 작업이 끝날 때까지 기다립니다. 빠른 결과 하나를 찾은 뒤 여러 느린 워커를 기다리면 호출자의 총 지연이 승자의 보고된 지연 시간과 전혀 다르게 보일 수 있습니다.

시작하기 전에 경쟁을 제한하라

  • 무제한 공개 목록을 제출하는 대신 동시 검사 수를 제한하십시오. 무료 프록시 목록은 검사기의 입력에 후보를 제공하며, 각 엔드포인트의 프로토콜은 워커를 위해 유지됩니다.
  • 각 요청에 적절한 연결 및 읽기 정책을 부여하십시오.
  • 호출자에게 전체 결정 예산을 부여하십시오.
  • 결정보다 오래 살아남는 워커의 결과를 누가 배출하거나 닫을지 정의하십시오.

Future를 덜 기다리는 것은 그 기반 요청을 더 짧게 만드는 것과 같지 않습니다. 마찬가지로 결과를 버린다고 해서 모든 네트워크 자원이 즉시 해제되지는 않습니다.

첫 번째 성공 결과 역시 첫 번째 성공 검사일 뿐입니다. 그것은 스케줄링, 캐시된 연결, 특정 검사 대상에 따라 달라질 수 있습니다. 엔드포인트가 보편적으로 가장 빠르다거나 실제 작업이 성공할 것이라는 점을 증명하지 않습니다.

종종 최근 관측을 가진 작은 유지 풀이 다운로드마다 전체 목록과 경쟁하는 것보다 간단합니다. 실제 작업의 결과를 사용해 기록을 업데이트하고, 실패에 대한 통제된 복구 정책을 함께 사용하십시오. 사전 검사는 습관적으로 모든 작업을 두 배로 늘리는 대신 비용을 정당화해야 합니다.

관련 글