Guzzle-ის მოთხოვნა შეიძლება დროის ლიმიტს გასცდეს კავშირის სლოტის ლოდინისას
დააყენეთ cURL multi-ს აქტიური კავშირების ბიუჯეტები საერთო handler-ზე და გამოყავით ისინი უმოქმედო ქეშის ტევადობისგან.
თუ ასინქრონული მოთხოვნა ვადამდე ამოიწურება კავშირის გახსნამდე, შეამოწმეთ ტრანსპორტის აქტიური ლიმიტები და ასევე ქსელის დროის ლიმიტები. როცა ეს ლიმიტები დაკავებულია, libcurl გადაცემებს რიგში აყენებს, და მათი დროის ბიუჯეტები რიგში ყოფნისას გრძელდება.
Guzzle 7-ის საერთო cURL multi handler-ისთვის:
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 | ერთდროულად გახსნილი კავშირები multi handler-ის ქვეშ |
| MAX_HOST_CONNECTIONS | კავშირები ერთ ჰოსტთან/პორტთან; პროქსის კავშირები ითვლება პროქსის ბოლო წერტილზე |
| MAXCONNECTS | კავშირები, რომლებიც გამოყენების შემდეგ ქეშში რჩება |
ერთი და იმავე პროქსის გამოყენებული რამდენიმე ვებსაიტი ავტომატურად არ იღებს ცალკე პროქსი კავშირების კვოტებს. უმოქმედო ქეშის ტევადობა არც წინასწარ ხსნის კავშირებს და არც მათ ურთიერთშემცვლელს ხდის: ხელახალი გამოყენება დამოკიდებულია მარშრუტზე, დანიშნულებაზე, პროტოკოლსა და აუთენტიფიკაციაზე.
შეინარჩუნეთ აპლიკაციის ამოცანების ბიუჯეტი და ნებისმიერი პროვაიდერის კვოტა ამ სატრანსპორტო ბიუჯეტების შესაბამისად. ისინი ითვლიან კავშირებს და არა მოთხოვნებს წამში. socket-ის დროის ლიმიტის გაზრდა ვერ დაადგენს, რიგმა თუ ქსელის ლოდინმა დახარჯა დრო.