GuzzleHttp 并发请求应该怎么写?
use GuzzleHttp\Client;
use GuzzleHttp\Promise;
$client = new Client(['base_uri' => API_URL]);
$promises = [];
$promises[] = $client->getAsync('/path');
$promises[] = $client->getAsync('/path');
$promises[] = $client->getAsync('/path');
$promises[] = $client->getAsync('/path');
$responses = Promise\Utils::unwrap($promises);
foreach ($responses as $key => $response) {
// todo
}
想请问一下,我使用 GuzzleHttp 这样写的请求是顺序执行的,不是并发请求。
应该怎么写才是并发请求?
我记得有个请求池
guzzle-cn.readthedocs.io/zh_CN/lat...
stackoverflow.com/questions/460155...
www.amitmerchant.com/async-http-re...
这个上面两种方法我也测试了,一样不是并发
楼主你写的是异步
会不会这里所说的”并发”,其实就只是按顺序发起异步请求(这一部分执行很快很快,看起来就像是”并发”了),然后等所有请求完成响应…
执行的结果
所谓并发其实还有有个先后顺序,只不过差距很小,可以hu
如果改成下面这样执行
执行结果
异步并发:做个比喻,就好比田径比赛,8个人一起从起点开始(并发),相当于8个线程,发令枪一响,同时开始,到达终点有先后顺序(异步),并不是按照赛道顺序。如果理解有误,欢迎指正
@Geroge 感谢回复,我的理解是跟你一样的,到达时间有先后,但是随着比赛的人增加,最后到达的那个人,不应该越来越慢。
我这边的例子就是请求数量越多,总耗时越长,所以我的结论是顺序请求【类似于接力比赛】,一个请求结束了,才请求下一个。
你的代码改成这个样子,是不是也能得出和我一样的结论?
以下代码并发请求10次。请求响应内容为:
{请求发起序号}:{请求响应序号}
根据实际测试,响应序号与发起序号无强相关,所以证明是并发的,而且
/test/index
中有1秒睡眠,10次请求实际只用4.08s,也证明了请求是并发的response:4.08s
单线程只能顺序执行哦,要实现并发得多线程
hyperf协程搞