-
Notifications
You must be signed in to change notification settings - Fork 16
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
Apache connection pool instrumentation #457
Conversation
Generate changelog in
|
assertThat(client.getNumRoutes()).describedAs("routes").isEqualTo(1); | ||
assertThat(client.getPoolStats().getAvailable()) | ||
.describedAs("available") | ||
.isEqualTo(0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think graphing the number available
will be kinda interesting, as this should tell us how quickly we could handle bursts of traffic
/**
* Gets the number idle persistent connections.
* <p>
* The total number of connections in the pool is equal to {@code available} plus {@code leased}.
* </p>
*
* @return number idle persistent connections.
*/
public int getAvailable() {
PoolingHttpClientConnectionManager connectionManager = new PoolingHttpClientConnectionManager( | ||
RegistryBuilder.<ConnectionSocketFactory>create() | ||
.register("http", PlainConnectionSocketFactory.getSocketFactory()) | ||
.register("https", sslSocketFactory) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we can wrap these to add a meter of connection rate, and wrap the pool manager to capture the rate connections requested?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mmm that would be cool, so dividing one by the other tells us how effectively we're re-using... Do we not already get that connection rate from the tritium tls.handshakes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tritium handshake instrumentation would work assuming https, but I don’t think we wire it up yet.
Closing in favour of #498 |
Before this PR
We have hypotheses that connection re-use has a big impact on our most performance-sensitive services like timelock. Currently, we just use the tls.handshake graphs to
After this PR
==COMMIT_MSG==
Each closeable apache client now exposes methods which reveal statistics about the connection pool.
==COMMIT_MSG==
After merging, we'll have to carefully wire these up to gauges in witchcraft, ensuring that we don't prevent objects from being GC'd just by having a reference in a tritium registry somewhere.
Possible downsides?