Se nesinkrona peto eksvalidiĝas antaŭ ol malfermi konekton, kontrolu la aktivajn limojn de la transporto same kiel la retajn tempolimojn. libcurl vicigas transigojn kiam tiuj limoj estas okupitaj, kaj iliaj tempolimaj buĝetoj daŭras dum ili staras en la vico.

Por la komuna cURL-multi traktilo de 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),
]);

Uzu ĉi tiun klienton por la nesinkrona laboro kaj donu ĝian celitan prokuran opcion al la operacioj. La valoroj estas ekzemplaj buĝetoj. Por publikaj petoj permesitaj tra publika peranto, la listo de HTTP-prokuroj provizas kandidatojn por la prokuraj URL-oj de la operacioj.

OpcioBuĝeto
MAX_TOTAL_CONNECTIONSSamtempe malfermitaj konektoj sub la multa traktilo
MAX_HOST_CONNECTIONSKonektoj al unu gastiganto/pordo; prokuraj konektoj kalkuliĝas kontraŭ la prokura finpunkto
MAXCONNECTSKonektoj retenitaj en la kaŝmemoro post uzo

Pluraj retejoj uzantaj la saman prokuron ne aŭtomate ricevas apartajn prokuajn konektajn permesojn. La kapacito de la senokupa kaŝmemoro nek malfermas konektojn anticipe nek igas ilin interŝanĝeblaj: reuzo dependas de vojo, celo, protokolo kaj aŭtentikigo.

Tenu la taskan buĝeton de la aplikaĵo kaj eventualan provizantan permeson kongruaj kun ĉi tiuj transportaj buĝetoj. Ili kalkulas konektojn, ne petojn en sekundo. Pliigi soketan tempolimon ne povas montri ĉu vico aŭ reta atendo konsumis la tempon.

Rilataj artikoloj