Sæt hvert Guzzle-jobs proxy på den asynkrone operation, som poolen starter. Inden for et eksisterende klientopsætning bruges promise-fabrikker:

$operations = function () use ($client, $jobs) {
    foreach ($jobs as $id => $job) {
        yield $id => function () use ($client, $job) {
            return $client->requestAsync('GET', $job['url'], [
                'proxy' => $job['proxy'],
                'timeout' => 20,
            ]);
        };
    }
};

$pool = new GuzzleHttp\Pool($client, $operations(), [
    'concurrency' => 4,
]);
$pool->promise()->wait();

Hvert valideret job leverer en destination og en proxy. For en tilladte offentlig anmodning kan en HTTP-kandidat fra HTTP-proxy listen levere det jobs proxy-URL uden legitimationsoplysninger; valget sker, før dens fabrik kører. En PSR-7-anmodning beskriver HTTP-beskeden, mens disse send-indstillinger styrer transporten. At udskrive eller gemme en proxyværdi ved siden af beskeden kan ikke konfigurere en operation, der sender den på en anden måde.

Returnér requestAsync() fra fabrikken. Kald af synkron request() der kan blokere, mens poolen forsøger at starte samtidigt arbejde.

Tilføj callbacks for opfyldte og afviste resultater ved hjælp af applikationens eksisterende håndtering. Behold jobnøglen, id'et for den valgte proxy og forsøgsnummeret i begge udfald; afslutningsrækkefølgen adskiller sig fra inputrækkefølgen. Vælg ikke i hemmelighed et andet endpoint i fabrikken, efter at ét er registreret for jobbet.

Værdien for samtidighed begrænser denne pools arbejde. Flere job, der vælger én begrænset proxy eller konto, kan stadig kræve et separat budget for det endpoint.

Fortolk resultater efter fase: afvisning af destination, proxygodkendelse og forbindelsestimeout er forskellige udfald. De send-indstillinger, der beholdes med jobbet, viser, hvilken rute der gav hvert resultat.

Relaterede artikler