Aweomse, since majority of PaaS outhere have a bad habit of using a really outdated curl version. 🎉

@kelunik the test suite of the Messenger component is failing when usingAmpHttpClient, with:

Idle timeout reached for "http://0.0.0.0:9494/messages".

The reproducer is:

docker pull feathj/fake-sqsdocker run -d -p 9494:9494 --name sqs feathj/fake-sqsexport MESSENGER_SQS_DSN=sqs://localhost:9494/messages?sslmode=disable./phpunit src/Symfony/Component/Messenger/ -v --filter Sqs

At first, I thought the reason was the0.0.0.0 in the URL, but actually when I force127.0.0.1 instead, the timeout persists.

The test passes when using the curl or the native client.

The test passes when I use anUnlimitedConnectionPool instead ofConnectionLimitingPool.

@nicolas-grekas Do you still have your benchmarking script handy? I was wondering how the Amp client compares to curl, particularly for a single request and many requests to the same host, both HTTP/1.1 and HTTP/2.

Sure, here it is.
On h2, AMP is comparable to Curl.
On h1.1, AMP looks slower, dunno why.

<?phprequire__DIR__.'/vendor/autoload.php';$client =newSymfony\Component\HttpClient\AmpHttpClient(['http_version' =>1.1]);for ($i =0;$i <379; ++$i) {$uri ="https://http2.akamai.com/demo/tile-$i.png";$responses[] =$client->request('GET',$uri);}foreach ($client->stream($responses)as$response =>$chunk) {if ($chunk->isLast()) {// a $response completedecho'.';    }else {// a $response's got network activity or timeout    }}echo"\n";

Green.

Status: needs review

Thank you@nicolas-grekas.

@nicolas-grekas Thanks for the script again. I see the same results: About the same for HTTP/2, slower for HTTP/1.x. Will have to investigate what's slowing down HTTP/1.x.

I was fishing for a reason to have Amp's client be the default client, but I don't really have a compelling reason for that other than installation consistency and portability. 😝

Is there a way to suggest using Amp if the client falls back to usingNativeHttpClient?

Is there a way to suggest using Amp if the client falls back to using NativeHttpClient?

We already have an@trigger_error() inHttpClient::create() when curl is missing. Please submit a PR to add a similar one whenNativeHttpClient is used now :)