@sxbxjhwm #42 只是为了做不阻塞情况下的并发数量限制.

一个新的思路是,既然 curl_multi 的管道复用,会尽可能的使用已有连接,那么对于未超过限制的请求,每次创建一个 curl_multi_init 和 curl_init,并打开 curl_multi 的管道复用,对于超过限制的请求,就使用已存在的 curl_multi_init 再次发送一个新的 curl_init.至此,已经基本可以使用 curl_multi 实现我之前用 tcp 模拟时实现的全部功能.唯一的问题和之前测试结果一样,多个 curl_multi_init 实例同时存在同时执行时效率较差,比使用 tcp 模拟或使用全局唯一的 curl_multi_init 效率下降非常多.
@sxbxjhwm #39 仅供参考.

@sxbxjhwm 主要是使我的工具类可以在项目内尽量通用，尽量复用现有逻辑。而不是将每个地方都做很多修改。

@sxbxjhwm #35 测试时还发现一个有意思的事情,在设置了启用管道时,我的倾向是期望在没有超过并发数之前尽可能使用新的连接,虽然建连也有一点损耗但是由于获取数据比较慢,所以也会比复用已有连接更快.但是 curl 库的默认方式似乎是优先尽可能复用已有的链接,直到一条连接上传输的请求超过阈值之后,才会去开一个新的连接.鉴于这个倾向的不同,所以即使我的 curl 版本符合这个区间,也不是我期望的效果.

@sxbxjhwm #35 找到三个参数,按照 libcurl 文档的描述,搭配使用可以实现通过 http1.1 管道来控制并发的效果.CURLMOPT_PIPELINING,CURLMOPT_MAX_HOST_CONNECTIONS,CURLMOPT_MAX_PIPELINE_LENGTH.但是这三个参数如果搭配使用对 curl 的版本有着严格的要求,需要大于等于 7.30 小于 7.62.我这边版本和线上一致不符合这个区间.所以没有测试出全部效果.不过设置 CURLMOPT_PIPELINING 为 1 来启用管道是可以实现的.

@sxbxjhwm #35 好的.我了解一下.

@sxbxjhwm #33 是的,php-fpm 本身是同步的,总有一个地方要阻塞来获取网络请求的结果.

@sxbxjhwm #31 我这边需要在 fpm 环境来实现这些效果.加速一些页面的打开效率.所以不方便使用后台脚本的方式.除非再做一次 fpm 进程与后台脚本之间的信息交互,总之还是非常感谢您的持续回复,极大的拓宽了我对 curl_multi 的了解.

@sxbxjhwm 嗯看到了。问题还是那个，如果请求不是一起添加进去的，而是一个一个添加的话，程序将要么在超过并发限制时报错，要么在这时阻塞。没有其他的好办法。虽然 http1.1 的管道是一个建议最好不要使用或者少使用的特性，但是确实可以解决我遇到的问题。

@sxbxjhwm 好的 感谢。我参考一下。

找到一个参数，CURLMOPT_PIPELINING，也许有一些作用，周一尝试一下。感谢您的回复，让我对 curl 有了更多的理解。

更换了一个思路,使用全局唯一的 curl_multi_init,每次请求时创建 curl_init 并添加,然后执行一个循环的 curl_multi_exec,获取数据时执行 curl_multi_select 和 curl_multi_getcontent.整体性能和我使用 tcp 连接基本差不多.但是有两个问题,一是此时等待数据时针对某一个变量进行等待其实已经没有意义,需要等待所有结果返回时第一个 wait 才能返回,然后后面的 wait 就是立即返回.二是此时没有很好的方式来控制并发数,因为我无法在一个 curl_init 中不获取返回值的情况下再传输一次 http 请求数据,所以此时如果判断超过了并发限制,只能报错,无法自动处理.而使用 tcp 时由于 http1.1 的管道,我可以不读取第一次的响应结果直接再次发送第二个请求,然后按照顺序来获取每一个响应.

已实测 23 楼的想法实际性能很差.

@sxbxjhwm #20 一个可能可行的方案是,在一个 curl_multi 实例中只添加一个 curl 句柄,发送请求时执行 curl_multi_init,curl_init,curl_multi_add_handle 和 curl_multi_exec,读取结果时执行 curl_multi_select 和 curl_multi_getcontent 及关闭连接.也可以基本实现类似于 tcp 连接时将发送和读取分开的效果.经过包装后也可以实现我示例代码的效果.可是这样对于每一次请求,都需要一个 curl 实例和一个 curl_multi 实例.我觉得这不是一个好的思路.除此之外,我没有其他的思路.

@sxbxjhwm #20 另外,在 curl_multi_select 返回值为-1 时,建议主动增加延迟.在某些情况下可以防止 cpu 使用率异常过高的问题.

@sxbxjhwm #20 好的.

@sxbxjhwm #18 我之前试用过,可能了解的不够深入,但是确实无法实现我的要求,示例代码上面已经贴了,我无法使用 curl_multi 来做到这个效果,而这种效果对于我的项目来说是必要的.所以如果可以实现,您可以试着贴一段示例代码我借鉴一下.

@sxbxjhwm #13 还有一个问题是连接数量的限制,对于我们的业务场景而言,并发连接数是有上限的,比如 api 端并发限制设置为 10,我需要调用 50 次获取 50 个不同的数据,直接发送过去是必然要很多 503 的,直接使用原始 tcp 连接的话可以做到在固定的 tcp 连接数量的情况下来传递更多的请求.这个也是 curl_multi 很难控制的.

@sxbxjhwm #13 按照我在 demo 里面写的例子扩展一下,可以写出类似下面的代码

function testGetData(){

$result = Pool::call('GET','http://api.ipify.org/?format=json');

$decode_function = function($result){

return json_decode($result,true);

};

return new Decode($result,$decode_function);
}

$result1 = testGetData();

$result2 = testGetData();

Helper::wait($result1);

Helper::wait($result2);


这里面 testGetData 是可以被随意调用多次的,无需提前准备好全部调用,而且这个方法本身是可并发的,并且可以对返回值进行处理.如果使用 curl_multi 或者按照你的项目的示例的话,我不知道如何来实现这个效果.