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 using AmpHttpClient, with:

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

The reproducer is:

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

At first, I thought the reason was the 0.0.0.0 in the URL, but actually when I force 127.0.0.1 instead, the timeout persists.

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

The test passes when I use an UnlimitedConnectionPool instead of ConnectionLimitingPool.

@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.

<?php
  
require __DIR__.'/vendor/autoload.php';

$client = new Symfony\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 completed
        echo '.';
    } 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 using NativeHttpClient?

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

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