repeated gets with keep-alive

[jlpeabody]

Kind of new to the library here and new with the requirement of needing to use keep-alive. I guess I should also mention this is a client side use case.

Having skimmed over the RFC for HTTP/1.1 for keep-alive and what I believe I should expect... each of my GET requests originate from from a new port and I'm getting log entries that a new TLS handshake was started. The server is behind Cloudflare and the the response return times start off really nice (of course anything faster would be better) but after a small number of requests the responses go from 10-20 ms to 200-500 ms.

I have seen the examples out there where aio-http can make an insane number of request-response cycles per second but they are all showing hits to a wide range of domains - not sustained conversations to a single domain as in my use case.

Just started reviewing the client.py file here, making sure I'm understanding the documentation and examples correctly. Any pointers/help parallel to this effort would be great. TIA

[Dreamsorcerer]

Probably need a code example that demonstrates the problem in order for someone to help out.

[webknjaz]

FWIW it's reproducible on my machine after out patching that missing env var getter. I still don't know why but I wonder if the connection key is being somehow created inconsistently: https://github.com/aio-libs/aiohttp/blob/e74d40c/aiohttp/client_reqrep.py#L275 / https://github.com/aio-libs/aiohttp/blob/master/aiohttp/connector.py#L444.

[webknjaz]

I did some digging and I believe that the connections are not reused because you perform the queries simultaneously and HTTP requests can only reuse TCP connections that have received HTTP response over the wire and have been freed.

[webknjaz]

The default connection pool TCPConnector has is 100 and so you've just filled it in precisely. But if you set limit=5, for example, you'll only see 5 TLS handshakes in your log. This will mean that there's at most 5 simultaneous requests being made. Once one connection gets released upon consuming an HTTP response, another request picks it up.

[webknjaz]

Or you could also make use of the limit_per_host setting which defaults to unlimited.

[jlpeabody]

Thanks! My misunderstanding about what limit_per_host was doing under the hood. I have no idea what I was thinking. I have some more work to do on my end, the round trip time is all over the place but the log shows only one SSL handshake now and that's a big difference.

Now I'm looking to see where I can add logging to show block time of the messages in flight -- performance reporting on the host's responsiveness. The tasks are created in 21 ms, the first task complete notification comes 2.294 seconds after the task is added to the event loop and the last one follows 14.871 seconds later. But so many variables are included in that.

Is there a options to add logging to more effectively isolate the time the request-response is in flight without the delays of local processing time for things like the event loop, the delay between the task being added and the request hitting the wire?

[webknjaz]

Why would you expect keep-alive to use a different port? It is specifically designed to reuse an existing TCP connection that is already established. Hence the same pairs of source host/port + destination host/port on the transport level are used (for sending HTTP requests the to the same remote host:port).

[jlpeabody]

I wouldn't expect it to use a different port and I actually see that as being part of the problem. I totally agree with your assessment.

In this case I am sending the identical REST request multiple times to the same destination and in each request a new socket is opening up on the client side in whereas I would prefer each subsequent request to travel the same SLL path that has already been established from the initial request.