Guzzle 请求可能因等待连接槽位而超时

在共享 handler 上设置 cURL multi 的活动连接预算，并将其与空闲缓存容量区分开。

如果异步请求在打开连接之前就到期，除了网络超时，还要检查传输层的活动上限。当这些上限被占满时，libcurl 会把传输排队，而队列中的请求其超时预算仍在继续消耗。

对于 Guzzle 7 的共享 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),
]);

用这个客户端执行异步工作，并在操作上提供它预期的代理选项。这些数值只是示例预算。对于通过公共中介获准的公共请求，HTTP 代理列表可为操作的代理 URL 提供候选。

选项预算
MAX_TOTAL_CONNECTIONSmulti handler 下同时打开的连接数
MAX_HOST_CONNECTIONS到单个主机/端口的连接数；代理连接计入代理端点
MAXCONNECTS使用后保留在缓存中的连接数

多个网站使用同一个代理，并不会自动获得各自独立的代理连接额度。空闲缓存容量既不会预先打开连接，也不会让连接可以互换：复用取决于路由、目标、协议和认证。

让应用的任务预算和任何服务商配额与这些传输预算保持一致。它们统计的是连接数，而不是每秒请求数。调大 socket 超时无法判断究竟是排队还是网络等待消耗了时间。

相关文章