Click the “blue text” above to follow us
Have you ever encountered a situation where, during peak service hours, a large influx of users causes the system response speed to slow down to a crawl? The code logic seems fine, so why does it struggle under high concurrency? It’s likely that the issue lies not in your business logic, but in improper handling of HTTP connections. Today, we will discuss the HTTP client pooling technology in Go and see how to solve this frustrating problem.
go.
Why is your Go service overwhelmed by traffic?
Imagine a scenario where you run a restaurant, and for every customer that arrives, you assign a dedicated waiter. If 50 customers come in a day, you need 50 waiters! What a high cost! HTTP connections work similarly, as each time a connection is established, it goes through the TCP three-way handshake, TLS handshake (if HTTPS), and other processes, which consume significant resources.
Even worse, many developers tend to write code like this: send a request, establish a connection, and close it after use. What a waste! It’s like hiring a waiter, serving one customer, and then firing them, only to rehire for the next customer. What’s the smarter approach? Connection reuse! Keep established connections in a “pool” and retrieve them when needed, returning them after use. This is the core idea of pooling technology.
go1.
The Secret Weapon of Go’s Native Client
In fact, the <span>http.Client</span> in the Go standard library already has a built-in connection pool mechanism! This is known as the Keep-Alive mechanism. By default, it automatically reuses underlying TCP connections. Look at this code:
client := &http.Client{
Transport: &http.Transport{
MaxIdleConns: 100,
MaxIdleConnsPerHost: 10,
IdleConnTimeout: 90 * time.Second,
},
Timeout: 10 * time.Second,
}What do these parameters mean? MaxIdleConns is the maximum number of idle connections in the entire pool, while MaxIdleConnsPerHost is the maximum number of idle connections for a single host. Many performance issues arise here! The default value is only 2, which is too small! It’s like a restaurant only keeping two waiters; during peak hours, they will definitely be overwhelmed.
Interestingly, I once encountered a situation where the system’s CPU spiked to 90% during stress testing, and monitoring showed that a lot of time was spent on creating TCP connections. After adjusting the MaxIdleConnsPerHost parameter, the CPU immediately dropped to 30%. Isn’t that amazing? This is the power of pooling!
tcp.
TCP Keep-Alive Mechanism: Preventing “Zombie Connections”
Pooling technology is great, but it also brings new problems. Will connections “expire” if left too long? Yes! Just like food that spoils over time, TCP connections that are unused for a long time may be closed by firewalls or proxy servers, turning into “zombie connections”. You think the connection is still alive, but it’s actually dead.
This is where the TCP Keep-Alive mechanism comes into play. It periodically sends small packets to check if the connection is still alive. Setting it up in Go is also quite simple:
transport := &http.Transport{
MaxIdleConnsPerHost: 100,
IdleConnTimeout: 90 * time.Second,
DialContext: (&net.Dialer{
Timeout: 5 * time.Second,
KeepAlive: 30 * time.Second, // Keep-alive time
}).DialContext,
}Here, the KeepAlive parameter is set to send a keep-alive probe every 30 seconds. You can adjust this based on actual conditions, typically between 15-60 seconds is reasonable. In a high-frequency trading system I previously worked on, I adjusted this value to 15 seconds, which significantly improved connection stability.
Another important parameter is IdleConnTimeout, which controls the maximum lifespan of idle connections. Setting it too short can lead to frequent connection creation, while setting it too long can waste resources. Based on my experience, a range between 90 seconds to 5 minutes is a good choice.
Remember one thing: pooling technology is not a panacea. For APIs with low-frequency calls, the overhead of creating connections may be lower than maintaining a connection pool. It’s like your restaurant only having a few customers a day, yet hiring a bunch of waiters to be on standby every day; that would be a loss. Therefore, choose the appropriate pooling strategy based on the actual scenario.
Finally, if your service has particularly high performance requirements, you might want to try this little trick: enable GZIP compression. One line of code can do it:<span>Transport.DisableCompression = false</span>. This can reduce data transmission volume by 50%-70%, making it much faster! Of course, there will be some additional CPU overhead; this is a typical space-for-time strategy. If used well, the effect is immediate!
