Guzzle-versoek kan verstryk terwyl dit op 'n verbindingsgleuf wag
Stel cURL multi se aktiewe verbindingsbegrotings op die gedeelde handler en onderskei hulle van die ledige kas se vermoë.
As 'n asinchrone versoek verstryk voordat 'n verbinding oopgemaak word, ondersoek die vervoer se aktiewe limiete sowel as netwerk-tydsperke. libcurl stel oordragte in die ry wanneer daardie limiete vol is, en hulle tydsperke loop voort terwyl hulle in die ry staan.
Vir Guzzle 7 se gedeelde 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),
]);Gebruik hierdie kliënt vir die asinchrone werk en verskaf sy beoogde proxy-opsie op die bewerkings. Die waardes is voorbeeldbegrotings. Vir openbare versoeke wat deur 'n openbare tussenganger toegelaat word, bied die HTTP-proxylys kandidate vir die bewerkings se proxy-URL's.
| Opsie | Begroting |
|---|---|
| MAX_TOTAL_CONNECTIONS | Gelyktydig oop verbindings onder die multi-handler |
| MAX_HOST_CONNECTIONS | Verbindings na een gasheer/poort; proxy-verbindings tel teen die proxy-eindpunt |
| MAXCONNECTS | Verbindings wat ná gebruik in die kas gehou word |
Verskeie webwerwe wat dieselfde proxy gebruik, kry nie outomaties aparte proxy-verbindingstoelaes nie. Ledige kasvermoë maak nie verbindings vooraf oop nie en maak hulle ook nie onderling verwisselbaar nie: hergebruik hang af van roete, bestemming, protokol en verifikasie.
Hou die toepassing se taakbegroting en enige verskaffer-toelating in ooreenstemming met hierdie vervoerbegrotings. Hulle tel verbindings, nie versoeke per sekonde nie. Om 'n sok-tydsperk te verhoog kan nie vasstel of 'n ry of 'n netwerkwag die tyd opgeneem het nie.