თითოეული Guzzle სამუშაოს პროქსი მოათავსეთ იმ ასინქრონულ ოპერაციაზე, რომელსაც პული იწყებს. არსებული კლიენტის კონფიგურაციის შიგნით გამოიყენეთ promise-ფაბრიკები:

$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();

ყოველი დადასტურებული სამუშაო გვაძლევს დანიშნულებას და პროქსის. დაშვებული საჯარო მოთხოვნისთვის HTTP პროქსების სიიდან HTTP კანდიდატს შეუძლია მოგვცეს იმ სამუშაოს პროქსის URL-ის გარეშე სერტიფიკატი; არჩევა ხდება მისი ფაბრიკის გაშვებამდე. PSR-7 მოთხოვნა აღწერს HTTP შეტყობინებას, ხოლო ეს გაგზავნის პარამეტრები აკონტროლებს ტრანსპორტს. პროქსის მნიშვნელობის დაბეჭდვა ან შენახვა შეტყობინების გვერდით ვერ დააკონფიგურირებს ოპერაციას, რომელიც მას სხვაგვარად აგზავნის.

დააბრუნეთ requestAsync() ფაბრიკიდან. სინქრონული request()-ის გამოძახება იქ შეიძლება დაიბლოკოს, სანამ პული ცდილობს პარალელური მუშაობის დაწყებას.

დაამატეთ შესრულებული და უარყოფილი callback-ები აპლიკაციის არსებული დამუშავების გამოყენებით. შეინახეთ სამუშაოს გასაღები, არჩეული პროქსის იდენტიფიკატორი და ცდის ნომერი ორივე შედეგში; დასრულების რიგი განსხვავდება შეყვანის რიგისგან. სამუშაოსთვის ერთის ჩაწერის შემდეგ ფარულად არ აირჩიოთ სხვა საბოლოო წერტილი ფაბრიკაში.

პარალელურობის მნიშვნელობა ზღუდავს ამ პულის მუშაობას. რამდენიმე სამუშაო, რომელიც ირჩევს ერთ შეზღუდულ პროქსის ან ანგარიშს, მაინც შეიძლება მოითხოვდეს ცალკე ბიუჯეტს ამ საბოლოო წერტილისთვის.

განმარტეთ შედეგები ეტაპების მიხედვით: დანიშნულების უარყოფა, პროქსის ავთენტიფიკაცია და კავშირის დროის ამოწურვა სხვადასხვა შედეგია. სამუშაოსთან შენახული გაგზავნის პარამეტრები აჩვენებს, რომელმა მარშრუტმა მოგვცა თითოეული შედეგი.

დაკავშირებული სტატიები