You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At present, Go's http.Transport struct implements a connection pool with a few tunable parameters to manage the lifecycle of connections within this pool.
Unlike the similar connection pooling behaviour of sql.DB, there is no (first-class) way to access statistics about how many connections are active, idle or waiting.
This makes it quite difficult to figure out what the optimal numbers for connection limits, idle limits and idle timeouts should be.
I found this issue which suggested something in that general direction, but it begins with a solution rather than a problem statement.
There is also this package which implements such tracking via a a custom DialContext to infer the state of the pool - although it appears to be now be unmaintained.
I think an API similar to sql.DB's Stats() method would suit my needs, but it may be that others have drawn lessons from that implementation which they would prefer not to repeat?
The text was updated successfully, but these errors were encountered:
At present, Go's
http.Transport
struct implements a connection pool with a few tunable parameters to manage the lifecycle of connections within this pool.Unlike the similar connection pooling behaviour of
sql.DB
, there is no (first-class) way to access statistics about how many connections are active, idle or waiting.This makes it quite difficult to figure out what the optimal numbers for connection limits, idle limits and idle timeouts should be.
I found this issue which suggested something in that general direction, but it begins with a solution rather than a problem statement.
There is also this package which implements such tracking via a a custom DialContext to infer the state of the pool - although it appears to be now be unmaintained.
I think an API similar to
sql.DB
'sStats()
method would suit my needs, but it may be that others have drawn lessons from that implementation which they would prefer not to repeat?The text was updated successfully, but these errors were encountered: