Guzzle 요청은 연결 슬롯을 기다리는 동안 시간 초과될 수 있습니다

공유 핸들러에서 cURL multi의 활성 연결 예산을 설정하고 유휴 캐시 용량과 구분하세요.

비동기 요청이 연결을 열기 전에 만료된다면 네트워크 시간 제한뿐 아니라 전송 계층의 활성 한도도 확인하세요. libcurl은 그 한도가 가득 차면 전송을 대기열에 넣고, 대기하는 동안에도 시간 제한 예산은 계속 흘러갑니다.

Guzzle 7의 공유 cURL multi 핸들러의 경우:

use GuzzleHttp\Client;
use GuzzleHttp\HandlerStack;
use GuzzleHttp\Handler\CurlMultiHandler;

$multi = new CurlMultiHandler([
    'options' => [
        CURLMOPT_MAX_TOTAL_CONNECTIONS => 24,
        CURLMOPT_MAX_HOST_CONNECTIONS => 4,
    ],
]);
$client = new Client([
    'handler' => HandlerStack::create($multi),
]);

이 클라이언트를 비동기 작업에 사용하고 작업에 원래의 프록시 옵션을 지정하세요. 값은 예시 예산입니다. 공개 중개자를 통해 허용되는 공개 요청의 경우 HTTP 프록시 목록이 작업의 프록시 URL 후보를 제공합니다.

옵션예산
MAX_TOTAL_CONNECTIONS멀티 핸들러 아래에서 동시에 열린 연결
MAX_HOST_CONNECTIONS단일 호스트/포트로의 연결. 프록시 연결은 프록시 엔드포인트에 대해 계산됨
MAXCONNECTS사용 후 캐시에 유지되는 연결

같은 프록시를 쓰는 여러 웹사이트가 자동으로 별도의 프록시 연결 할당량을 받지는 않습니다. 유휴 캐시 용량은 연결을 미리 열지 않고 서로 교환 가능하게 만들지도 않습니다. 재사용은 경로, 대상, 프로토콜, 인증에 따라 달라집니다.

애플리케이션 작업 예산과 공급자 할당량을 이 전송 예산과 일치시키세요. 이들은 초당 요청 수가 아니라 연결 수를 셉니다. 소켓 시간 제한을 늘려도 대기열과 네트워크 대기 중 어느 쪽이 시간을 썼는지 알 수 없습니다.

관련 글