TCPConnector / enable limit_per_url

[copdips]

Is your feature request related to a problem?

No response

Describe the solution you'd like

currenly we have limit and limit_per_host optiions, but my use case is that, I have many API behind the same host, but only one of them has the max concurrent reuqests limit, so I need a new param like limit_per_url, ideally with the http method also.

Describe alternatives you've considered

currently, I'm using asyncio.semaphore to achieve that.

Related component

Client

Additional context

aiohttp.TCPConnector

Code of Conduct

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

[Dreamsorcerer]

My first thought is that this is probably intended to be done by creating 2 connectors/sessions and having different parameters for each.

[copdips]

Yes, using multiple sessions can work as well. However, my actual use case involves having multiple endpoints behind the same host, each with different maximum concurrency limits. Managing multiple sessions might become burdensome due to the need for numerous variables in the code and extensive conditional logic to select the appropriate session object for different endpoints, etc.

That's why I asked for limit_per_url as a nice wraper to move all these "heavy works" from user code into aiohttp.

[copdips]

I can even envision, if possible, having two levels of sessions.

The first level would involve creating multiple sessions for different groups of endpoints, such as a session for financial team endpoints, another for sales team endpoints, and one more for technical team endpoints, etc.

The second level would entail, within each session, leveraging limit_per_url or limit_per_endpoint (including the HTTP verb) to achieve fine-grained control.

All these sessions will target to the same host, as entreprises often use an API gateway in front of all the private APIs.

[Dreamsorcerer]

Managing multiple sessions might become burdensome due to the need for numerous variables in the code and extensive conditional logic to select the appropriate session object for different endpoints, etc.

I think that's called a dict. ;)

I'm not saying that it's a terrible idea, but it seems like a bit of an obscure use case we'd then need to maintain. It could also have a performance impact on other users depending on how it's implemented. So, I suspect there won't be much interest in implementing it. Either way, if you want something that works now (or even this year), you'll be best using multiple sessions.

[copdips]

thanks for your shares, I'll close this request.