Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Http Client Channel Pool Metrics #26

Open
dthoffdev opened this issue Jun 14, 2019 · 6 comments
Open

Feature Request: Http Client Channel Pool Metrics #26

dthoffdev opened this issue Jun 14, 2019 · 6 comments
Labels
type: enhancement New feature or request

Comments

@dthoffdev
Copy link

It would be nice to have visibility into what is happening in the channel pools of http clients. For example the number of channels checked out, pending acquires, rate/number of new connections created, timings on how long it took to open a new connection, etc.

@graemerocher graemerocher transferred this issue from micronaut-projects/micronaut-core Jun 17, 2019
@graemerocher graemerocher added the type: enhancement New feature or request label May 20, 2020
@eutkin
Copy link

eutkin commented Sep 2, 2021

Yes, this functionality is very much needed. We are seeing performance issues related to connection pooling

@jjathman-ch
Copy link

@graemerocher I realize this issue is quite old, do you know if an implementation of this would be relatively straightforward for someone to contribute it? I'd be happy to try and take this on but I'm a bit worried the HTTP connection pooling code is too complex for someone outside the Micronaut core team.

Our main use case is we would like to understand better if we are maxing out our HTTP connection pools or not but as far as I know there's no way to know that currently.

@graemerocher
Copy link
Contributor

@yawkat would know more

@yawkat
Copy link
Member

yawkat commented Sep 3, 2024

Depends on the metrics. imo ConnectionManager is fairly clean nowadays, and I think the "state" metrics (e.g. number of open connections) should be fairly easy with access to PoolResizer. Timing metrics may be more difficult because the code is very asynchronous

@jjathman-ch
Copy link

jjathman-ch commented Sep 3, 2024

@yawkat thank you. Do you think updating the state of the metrics within the PoolResizer#doSomeWork method would be a reasonable approach? I think just these metrics would be enough for me:

pendingRequestCount
pendingConnectionCount 
http1ConnectionCount
http2ConnectionCount

@yawkat
Copy link
Member

yawkat commented Sep 3, 2024

sure

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement New feature or request
Projects
Development

No branches or pull requests

5 participants