Si une requête asynchrone expire avant d'ouvrir une connexion, examinez les limites actives du transport ainsi que les délais réseau. libcurl met les transferts en file lorsque ces limites sont saturées, et leurs budgets de délai continuent de s'écouler pendant l'attente.

Pour le gestionnaire cURL multi partagé 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),
]);

Utilisez ce client pour le travail asynchrone et fournissez son option de proxy prévue sur les opérations. Les valeurs sont des budgets d'exemple. Pour les requêtes publiques autorisées via un intermédiaire public, la liste de proxies HTTP fournit des candidats pour les URL de proxy des opérations.

OptionBudget
MAX_TOTAL_CONNECTIONSConnexions ouvertes simultanément sous le gestionnaire multi
MAX_HOST_CONNECTIONSConnexions vers un seul hôte/port ; les connexions proxy sont comptées sur le point de terminaison du proxy
MAXCONNECTSConnexions conservées dans le cache après usage

Plusieurs sites utilisant le même proxy ne reçoivent pas automatiquement des quotas de connexions proxy séparés. La capacité du cache inactif n'ouvre pas de connexions à l'avance et ne les rend pas interchangeables : la réutilisation dépend de la route, de la destination, du protocole et de l'authentification.

Gardez le budget de tâches de l'application et tout quota du fournisseur cohérents avec ces budgets de transport. Ils comptent des connexions, pas des requêtes par seconde. Augmenter le délai d'expiration du socket ne permet pas de savoir si une file d'attente ou une attente réseau a consommé le temps.

Articles similaires