Guzzle pieprasījums var beigties ar noildzi, gaidot savienojuma vietu
Iestatiet cURL multi aktīvos savienojumu budžetus koplietotajā apstrādātājā un atšķiriet tos no neaktīvā kešatmiņas apjoma.
Ja asinhronais pieprasījums beidzas ar noildzi pirms savienojuma atvēršanas, pārbaudiet transporta aktīvos ierobežojumus un arī tīkla noildzes. Kad šie ierobežojumi ir aizņemti, libcurl ievieto pārsūtīšanas rindā, un to noildzes budžeti turpinās, kamēr tās atrodas rindā.
Guzzle 7 koplietotajam cURL multi apstrādātājam:
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),
]);Izmantojiet šo klientu asinhronajam darbam un operācijās norādiet paredzēto starpniekservera opciju. Vērtības ir parauga budžeti. Publiskiem pieprasījumiem, kas atļauti caur publisku starpnieku, HTTP starpniekserveru saraksts piedāvā kandidātus operāciju starpniekservera URL.
| Opcija | Budžets |
|---|---|
| MAX_TOTAL_CONNECTIONS | Vienlaikus atvērti savienojumi zem multi apstrādātāja |
| MAX_HOST_CONNECTIONS | Savienojumi ar vienu resursdatoru/portu; starpniekservera savienojumi tiek skaitīti pret starpniekservera galapunktu |
| MAXCONNECTS | Savienojumi, kas pēc lietošanas paliek kešatmiņā |
Vairākas vietnes, kas izmanto vienu un to pašu starpniekserveri, automātiski nesaņem atsevišķas starpniekservera savienojumu kvotas. Neaktīvā kešatmiņas apjoms nevis atver savienojumus iepriekš, ne arī padara tos aizvietojamus: atkārtota izmantošana ir atkarīga no maršruta, galamērķa, protokola un autentifikācijas.
Turiet lietojumprogrammas uzdevumu budžetu un jebkuru pakalpojumu sniedzēja kvotu saskaņotu ar šiem transporta budžetiem. Tie skaita savienojumus, nevis pieprasījumus sekundē. Ligzdas noildzes palielināšana nevar noteikt, vai laiku patērēja rinda vai tīkla gaidīšana.