Go语言实现HTTP并发压测工具教程

本文深入剖析了Go语言中HTTP并发压测QPS上不去的根本原因——源于`http.DefaultClient`默认Transport连接池参数过于保守（如`MaxConnsPerHost=2`），导致大量goroutine阻塞在连接获取阶段；文章手把手教你如何通过自定义`http.Client`、科学调优`MaxConnsPerHost`、`MaxIdleConns`、`IdleConnTimeout`等关键参数，结合`time.Ticker`实现精准RPS限速、`sync.WaitGroup`合理控制协程规模，并辅以`ulimit`和`Context`超时管理，构建稳定、高效、可复现的压测工具——告别“一窝蜂”式并发，真正释放Go高并发潜力。

用 http.DefaultClient 发起并发请求时，为什么 QPS 上不去？

默认的 http.DefaultClient 底层复用 http.Transport，但它的连接池参数保守：默认只允许 2 个并发连接到同一 host（MaxConnsPerHost = 2），且空闲连接 30 秒后复用失效。压测时大量 goroutine 卡在等待连接，QPS 被硬限在极低水平。

• 必须显式配置 http.Transport，重点调大 MaxConnsPerHost（如设为 100 或 0 表示无限制）和 MaxIdleConns
• IdleConnTimeout 建议设为 90 秒以上，避免频繁建连；TLSHandshakeTimeout 加上，防止 TLS 握手卡死整个 goroutine
• 别直接改 http.DefaultClient —— 它是全局单例，会影响其他模块；应新建独立 http.Client

client := &http.Client{
    Transport: &http.Transport{
        MaxConnsPerHost:        100,
        MaxIdleConns:           100,
        IdleConnTimeout:        90 * time.Second,
        TLSHandshakeTimeout:    10 * time.Second,
    },
}

用 sync.WaitGroup 控制并发数，但压测结果波动极大

单纯靠 WaitGroup.Add(n) 启动 n 个 goroutine，看似并发了，实际是“一窝蜂”发起请求，没做速率控制。网络抖动、服务端限流、本地文件描述符耗尽都会导致失败率飙升、RT 毛刺严重，数据不可信。

• 必须引入固定速率（如 RPS），用 time.Ticker 驱动每次发请求，而不是一次性拉满 goroutine
• goroutine 数量 ≠ 并发连接数；建议 goroutine 数略大于目标 RPS（比如 RPS=500，开 64 个 goroutine），每个 goroutine 循环取 <-ticker.C 发请求
• 注意 ulimit -n，Linux 默认 1024，压测前至少设为 65535，否则报 dial tcp: lookup xxx: no such host 或 too many open files

http.Request 的 Context 超时设置不生效？

常见错误是只给 http.Client.Timeout，但没传 context.Context 到 client.Do()，或用了 context.Background() 却没设 deadline。结果请求卡住几十秒不返回，压测进程 hang 死。

• 必须用 context.WithTimeout(ctx, reqTimeout) 创建带超时的 context，并传给 client.Do(req.WithContext(ctx))
• client.Timeout 只控制整个 Do 过程（含 DNS、连接、写请求、读响应头），不包含读响应体；若要限制全文读取，需在 Response.Body 上手动加 io.LimitReader 或用 http.MaxBytesReader
• 别忽略 err 类型：网络错误是 *url.Error，服务端返回 5xx 是 nil err + 非 2xx resp.StatusCode，二者统计逻辑不同

压测中如何准确统计成功率、P95、QPS？

用 time.Now() 手动打点再排序算 P95，容易因 GC、调度延迟引入毫秒级误差；而每请求都 fmt 打 log 会拖慢 3–5 倍性能，数据也不准。

• 用 runtime.GC() 在压测前手动触发一次，减少压测中 STW 干扰
• 响应时间存进预分配的 []int64（容量等于总请求数），用 sort.Slice() 算分位值；避免 map 或 channel 聚合，它们有锁或调度开销
• QPS 不要用 “总请求数 / 总耗时”，而是用滑动窗口：每秒计数器用 atomic.Int64，每秒重置并输出，更反映瞬时压力
• 注意时钟源：Linux 上优先用 time.Now().UnixNano()，别用 time.Since() 套嵌套，它内部也调 Now()

真实压测里最常被跳过的，是服务端日志采样率、客户端 DNS 缓存、以及 TCP TIME_WAIT 占满端口导致新连接失败 —— 这些不会报错，但会让结果看起来“不稳定”。

今天带大家了解了的相关知识，希望对你有所帮助；关于Golang的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~