Do concurrent client connections get created sequentially?

[hlecnt]

Hi all,

While investigating on a global performance issue on my aiohttp app (Python 3.10, aiohttp 3.9.3) I noticed that a significant amount of time is spent in the client session request() call when concurrent request are made. This was confirmed by enabling Tracing on some requests.

So I've developed a little docker app performing concurrent request to an Nginx server. It is available here: https://github.com/hlecnt/aiohttp-load-test-2/tree/master

By default it will generate 2 iterations of 500 concurrent requests to the Nginx server.
A tcpdump is done during the test.
The first iteration takes more time is than the second to complete. For me, this is expected because of the need to create connections with the upstream server.

But I observed that the first request is really sent only when all connections to the upstream server are established. And these connections are established sequentially (confirmed by the tcpdump). I have tested on a Google VM and a WSL intance with the same result.
Performing the same test by sending the request sequentially (in a for loop) instead of concurrently (gather()) gives better timings (TCPConnector reuse the same connection). This was unexpected but may be due to the test itself: nginx answers very quickly here.

I am wondering if this sequential creation of TCP connections is an expected behavior?
Personally I was expecting HTTP request sent before all the connections are setup. But this behavior may be due to the test configuration itself.

The second point is the total time spent to process the request, while it takes less than 1ms on the nginx side, it take about 500ms on my WSL to complete the 500 request.
I know that I can't compare aiohttp with other server like nginx, but the total processing time seems to be 'too' high.

Any comment will be appreciated.

Best regards,

---

Please find attached an archive with 2 tcpdump (50 requests sent concurrently versus sequentially)
dump-50-2iter.zip

[bdraco]

When you do a gather there is a race to make connections to the remote host.

The performance is frequently better when the server supports keep alive by awaiting requests in sequence (which has less task overhead for small requests) or using a semaphore to reduce the concurrency of tasks since it's more likely to see connection reuse.

[bdraco]

I got rid of another task creation in #8163 for dns hit, but I think getting rid of the one that was introduced in #3406 is difficult to do.

[bdraco]

If you can do py3.12 you can use https://docs.python.org/3/library/asyncio-task.html#eager-task-factory.

You could also borrow this helper https://github.com/home-assistant/core/blob/f3594c543d2a923b57218c13a3f0b5bb9927588f/homeassistant/util/async_.py#L27

[hlecnt]

Thanks for your answers!
It seems that I'm on the right way. I'll get a try to Python 3.11 first, but I need some time to migrate the code properly.

[hlecnt]

Hi,

Just a word before closing the discussion. Moving to Python 3.11 and some optim in my code have fixed performance issues.
Thanks for your help @bdraco.

[bdraco]

#8661 will take care of the one I mentioned above when using python 3.12+