Nice! Tracking connection reuse is really important if you are running any kind of benchmarks or comparisons both as the author of a new tool / service and as the person evaluating different options or client libraries.
I've hit a lot of walls not ensuring I was using connection pools correctly even when the service I'm calling was local/docker. File descriptor exhaustion happens often if you're not careful.
Author here... Thanks for sharing this. It has been fun to use while we get ready to launch https://probes.dev with tracing being core to the service.
I wish I had known this two years ago. I ended up writing my own embedded connection struct to trace these things [0].
type Connection struct {
net.Conn
OnEventCallback func(clientClosed bool, serverClosed bool, err error)
}
[0] https://github.com/s-macke/SlapperX/blob/master/src/tracing/...hn title mangling strikes again.
Little things like this are why Go is great. People make arguments against Go based just on available language syntax, but languages are more than just syntax; it is about the end-to-end development flow. I actually think C# and the .NET platform are the only other ecosystem that looks at development the same way. In most other ecosystems, you almost always need to step outside what the built-in language platform provides for any moderately complicated use-case.