Currently we cannot measure the current connection count in Skipper. This would be useful for various reasons, one of the is to have clues for the right size of the used connection pool.
We should measure the following things:
incoming TCP connections
outgoing TCP connections
pending HTTP requests
Incoming/Outgoing TCP connections
Easy to detect when new connections are created, but somewhat tricky to detect when they are closed/broken. In case of the incoming connections, solutions seem to generally rely on the connections' Close method always being called, and this is relatively easy to verify in the server code of the standard library. In case of the outgoing connections, the best way seems to be to try the net/http/httptrace library, and see how it works out.
Pending requests
The best solution for this is measuring the pending requests on a global LIFO queue (it's built to be cascadable), that protects the skipper instance.
Connection metrics
Currently we cannot measure the current connection count in Skipper. This would be useful for various reasons, one of the is to have clues for the right size of the used connection pool.
We should measure the following things:
incoming TCP connectionsIncoming/Outgoing TCP connectionsEasy to detect when new connections are created, but somewhat tricky to detect when they are closed/broken.
In case of the incoming connections, solutions seem to generally rely on the connections' Close method always being called, and this is relatively easy to verify in the server code of the standard library.In case of the outgoing connections, the best way seems to be to try the net/http/httptrace library, and see how it works out.Pending requests
The best solution for this is measuring the pending requests on a global LIFO queue (it's built to be cascadable), that protects the skipper instance.