The HttpClient does a superb job to run pending requests virtually "in the background", concurrently. However, this does not happen when using the CachingHttpClient.

Example code:

use Symfony\Component\HttpClient\CachingHttpClient;
use Symfony\Component\HttpClient\HttpClient;
use Symfony\Component\HttpKernel\HttpCache\Store;

require('vendor/autoload.php');

$httpClient = new CachingHttpClient(HttpClient::create(), new Store('store'));
# $httpClient = HttpClient::create();

$response1 = $httpClient->request('GET', 'http://httpbin.org/delay/2');
$response2 = $httpClient->request('GET', 'http://httpbin.org/delay/2');
$response3 = $httpClient->request('GET', 'http://httpbin.org/delay/2');

$x = $response1->getContent(); print "1\n";
$y = $response2->getContent(); print "2\n";
$z = $response3->getContent(); print "3\n";

(Note: The responses from httpbin.org above are not cacheable. So although all three requests above are for the same resource, you will always see three cache misses.)

The execution time for the above script is somewhat above 6 seconds. If you change the commented-out line to use the plain HttpClient, it's just above 2 seconds, because the requests happen in parallel once the first call to getContent() is made.

My assumption is that the HttpClient does some magic trickery 🧙 🧪, probably outside PHP userland, to achieve this level of concurrency.

The cache implementation, however, is written in PHP. We have to check the cache for every requested resource to find out if we need to make a remote request at all, whether it needs to be a revalidation or plain fetch, and we need to possibly cache the responses afterwards.

This adds to #36858 – we need a more dedicated cache implementation to support it.