While reading the draft Go 1.28 release notes, I noticed a change in the HTTP/2 server. With this change, the goroutine responsible for serving a connection can exit when there is no work to do, instead of waiting. A new goroutine takes over when needed. At first, it seemed like a small change, but I wondered how much memory it could save on a server with thousands of open connections.

I decided to measure it rather than guess. I wanted to see how it affected process memory usage, goroutine counts, and Go runtime memory metrics.

What is HTTP/2 parking?

An HTTP/2 connection can stay open even when it has no active streams. In the older server behavior, a goroutine runs the connection's serveLoop and waits there when nothing new is ready. The Go 1.28 development code adds an internal mechanism called parking . When serveLoop has no work ready to process, and the implementation's safety conditions are met, that goroutine can exit.…