Golang实现HTTP并发压测工具性能分析

本文深入剖析了使用 Golang 的 `http.DefaultClient` 进行 HTTP 并发压测时极易踩坑的关键细节——看似简单的 `go client.Do(req)` 并发调用，实则因连接池耗尽、DNS 频繁解析、goroutine 泛滥、响应体未关闭、FD 泄漏及 GC 干扰等问题，导致服务未压垮而客户端先崩盘；文章直击本质，给出可落地的高性能压测配置方案：自定义 `http.Transport` 调优连接池与超时、禁用低效 DNS 解析、用信号量或 worker 池硬限并发、强制关闭 `resp.Body`、固定 `GOMAXPROCS` 并临时禁用 GC，真正实现“发得稳、收得准、测得真”。

怎么用 http.DefaultClient 发起并发请求不崩

Go 的 http.DefaultClient 默认复用连接，但压测时若不调优，很快会卡在 DNS 解析、连接池耗尽或 TCP TIME_WAIT 堆积上。关键不是“能不能发”，而是“发完能不能收、收得稳不稳”。

• http.DefaultClient.Transport 必须自定义：默认 MaxIdleConns 和 MaxIdleConnsPerHost 都是 100，压测 500 并发时直接排队等连接
• DNS 缓存要关或设长：默认 net.Resolver 不缓存，高频域名解析会阻塞 goroutine；可配 Transport.DialContext + net.Dialer.Timeout 控制建连超时
• 别用 time.Sleep 控制 QPS：goroutine 启太多又睡不齐，实际并发毛刺大；改用 time.Ticker 或带限速的 worker 池

示例关键配置：

tr := &http.Transport{
    MaxIdleConns:        2000,
    MaxIdleConnsPerHost: 2000,
    IdleConnTimeout:     30 * time.Second,
    TLSHandshakeTimeout: 10 * time.Second,
}
client := &http.Client{Transport: tr}

为什么 goroutine + http.Do 写法容易 OOM

常见写法是 for 循环里直接 go func() { client.Do(req) }()，看着简洁，实则危险——没做并发控制，瞬间几千 goroutine 启动，内存暴涨，调度器反成瓶颈。

• 每个 goroutine 至少占 2KB 栈空间，10k 并发 ≈ 20MB 内存起步，还没算响应体缓冲
• http.Do 是同步阻塞的，goroutine 等响应期间仍驻留，无法被 GC 回收
• 错误不收集：HTTP 错误码、timeout、connection refused 全被吞掉，压测结果失真

正确做法是加 channel 控制并发数，比如用带缓冲的 sem channel：

sem := make(chan struct{}, 100) // 限制 100 并发
for i := 0; i < total; i++ {
    sem <- struct{}{}
    go func() {
        defer func() { <-sem }()
        resp, err := client.Do(req)
        // 处理 resp/err
    }()
}

http.Response.Body 不 Close() 会导致什么

压测中常忽略 resp.Body.Close()，后果不是立刻报错，而是连接无法复用、文件描述符泄漏、后续请求变慢甚至失败。

• HTTP/1.1 默认 keep-alive，Body 不关 → 连接卡在 “idle” 状态，进不了连接池复用队列
• Linux 默认单进程 1024 fd 限制，压测几分钟就 hit too many open files
• 即使用了 io.Copy(ioutil.Discard, resp.Body)，也必须跟 resp.Body.Close()，否则底层 TCP 连接不释放

安全写法（带错误检查）：

resp, err := client.Do(req)
if err != nil {
    // 记录 err
    return
}
defer resp.Body.Close() // 注意：这里 defer 在 goroutine 里才有效
body, _ := io.ReadAll(resp.Body)
// 后续处理 body

怎么让压测结果不被 Go runtime 调度干扰

短时高压下，GC 频繁触发、P 数量波动、GMP 调度抖动，会让 p99 延迟虚高。这不是代码问题，是观测方式问题。

• 别只看平均 RT：压测 10 秒，前 2 秒 GC STW 可能拉高整体均值，掩盖真实服务瓶颈
• 运行前固定 GOMAXPROCS：比如 runtime.GOMAXPROCS(runtime.NumCPU())，避免测试中途动态扩缩 P
• 禁用后台 GC（仅限压测进程）：debug.SetGCPercent(-1)，测完再恢复；或用 GODEBUG=gctrace=1 观察 GC 频次
• 结果采集避开首尾 1 秒：warmup 和 cooldown 阶段数据噪声大，直接切片丢弃

复杂点在于：你永远分不清是服务慢了，还是 Go 自身调度卡了。所以压测时务必同时采集 runtime.ReadMemStats 和 debug.ReadGCStats，对照看。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Golang实现HTTP并发压测工具性能分析》文章吧，也可关注golang学习网公众号了解相关技术文章。