O cerere Guzzle poate expira în timp ce așteaptă un loc de conexiune

Setați bugetele de conexiuni active ale cURL multi pe handlerul partajat și distingeți-le de capacitatea cache-ului inactiv.

Dacă o cerere asincronă expiră înainte de a deschide o conexiune, verificați limitele active ale transportului, precum și timeout-urile rețelei. libcurl pune transferurile în coadă când aceste limite sunt ocupate, iar bugetele lor de timeout continuă în timp ce stau în coadă.

Pentru handlerul cURL multi partajat din Guzzle 7:

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),
]);

Folosiți acest client pentru munca asincronă și furnizați opțiunea de proxy prevăzută pe operațiuni. Valorile sunt bugete exemplu. Pentru cererile publice permise printr-un intermediar public, lista de proxy-uri HTTP oferă candidați pentru URL-urile de proxy ale operațiunilor.

OpțiuneBuget
MAX_TOTAL_CONNECTIONSConexiuni deschise simultan sub handlerul multiplu
MAX_HOST_CONNECTIONSConexiuni către un singur host/port; conexiunile proxy se contorizează față de punctul final al proxy-ului
MAXCONNECTSConexiuni păstrate în cache după utilizare

Mai multe site-uri care folosesc același proxy nu primesc automat cote separate de conexiuni proxy. Capacitatea cache-ului inactiv nu deschide conexiuni în avans și nu le face interschimbabile: refolosirea depinde de rută, destinație, protocol și autentificare.

Mențineți bugetul de sarcini al aplicației și orice cotă a furnizorului consecvente cu aceste bugete de transport. Ele numără conexiuni, nu cereri pe secundă. Creșterea timeout-ului socketului nu poate stabili dacă o coadă sau o așteptare de rețea a consumat timpul.

Articole similare