Add keepalive_requests and keepalive_time parameters for connection

[fighterhit]

Is your feature request related to a problem?

In the k8s environment, when the pod (behind ClusterIP Service) is scaled up, the new pod has almost no requests.

Describe the solution you'd like

When the k8s pod is scaled up, the connection number between the new and old pods remains relatively balanced

Describe alternatives you've considered

For example, nginx sets an upper limit on the number of requests and a time limit for each connection. If the limit is exceeded, the connection is disconnected, so that new pods of the service will also have the opportunity to receive new requests.
keepalive_requests
keepalive_time

Related component

Client

Additional context

When I was stress testing the backend service, after the k8s pod was scaled up, the CPU usage of the new and old pods differed greatly because the new pods had much fewer connections than the old pods.

Code of Conduct

• I agree to follow the aio-libs Code of Conduct

[webknjaz]

This doesn't look related to aiohttp.

[fighterhit]

This doesn't look related to aiohttp.

Hi @webknjaz , I think when the connection pool is basically sufficient and requests are continuous(<< keepalive_timeout), requests may always use old connections, and aiohttp client may rarely have the opportunity to establish new connections with new server instances (pods in k8s), resulting in load imbalance. If the connection is reestablished on a regular basis or based on the number of requests like nginx, this problem should be solved.

[webknjaz]

Are you saying you're actually using aiohttp and this is about the client side?

[fighterhit]

Are you saying you're actually using aiohttp and this is about the client side?

@webknjaz Yes, I use aiohttp ClientSession (with the default keepalive_timeout 15s), the server is built with fastapi and uvicorn, and the keepalive_timeout is 90s. I think the imbalance of the number of connections on the server side is caused by the aiohttp client not reestablishing the connection regularly, and the requests are always reusing the old connections.

[webknjaz]

Have you tried tweaking the pool size or setting up force close and similar settings?
https://docs.aiohttp.org/en/stable/client_advanced.html#limiting-connection-pool-size / https://docs.aiohttp.org/en/stable/client_reference.html#aiohttp-client-reference-connectors

[fighterhit]

Have you tried tweaking the pool size or setting up force close and similar settings? https://docs.aiohttp.org/en/stable/client_advanced.html#limiting-connection-pool-size / https://docs.aiohttp.org/en/stable/client_reference.html#aiohttp-client-reference-connectors

@webknjaz Yes, I have tried force close, but it will affect performance because each request will establish a new connection. I think the other configuration that limits the number of connections may not be related to this problem.

[webknjaz]

Honestly, there's not enough context to make any more guesses..

cc @Dreamsorcerer?

[Dreamsorcerer]

I think keepalive_timeout is the time the connection can be idle for. If the connection is not idle, then it won't close. Looks like there's a limit_per_host, though that's not exactly what you're looking for either.

We also now have a socket_factory, so if you can figure out any socket-level flags that achieve what you want, that would work. But, at the aiohttp level we don't have anything equivalent of those nginx options.

[fighterhit]

Thanks @Dreamsorcerer , the socket-level flags cannot solve this problem.