Guzzle Pool: skicka varje jobbs proxy till requestAsync
Koppla proxy-alternativ till varje asynkron operation i stället för till ett PSR-7-förfrågningsmeddelande eller en blockerande fabrik.
Sätt varje Guzzle-jobbets proxy på den asynkrona operation som poolen startar. Inom en befintlig klientuppsättning använder du löftesfabriker:
$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();
Varje validerat jobb tillhandahåller en destination och en proxy. För en tillåten offentlig begäran kan en HTTP-kandidat från HTTP-proxylistan tillhandahålla det jobbets proxy-URL utan inloggningsuppgifter; valet sker innan dess fabrik körs. En PSR-7-begäran beskriver HTTP-meddelandet, medan dessa sändningsalternativ styr transporten. Att skriva ut eller lagra ett proxyvärde bredvid meddelandet kan inte konfigurera en operation som skickar det på ett annat sätt.
Returnera requestAsync() från fabriken. Att anropa synkron request() där kan blockera medan poolen försöker starta samtidigt arbete.
Lägg till callbacks för uppfyllda och avvisade resultat med applikationens befintliga hantering. Behåll jobbnyckeln, identifieraren för vald proxy och försöksnumret i båda utfallen; slutförandeordningen skiljer sig från inmatningsordningen. Välj inte i hemlighet en annan slutpunkt i fabriken efter att en registrerats för jobbet.
Värdet för samtidighet begränsar den här poolens arbete. Flera jobb som väljer en enda begränsad proxy eller ett konto kan fortfarande behöva en separat budget för den slutpunkten.
Tolka resultat per fas: avvisning av destination, proxyautentisering och anslutningstimeout är olika utfall. Sändningsalternativen som behålls med jobbet visar vilken väg som gav varje resultat.