17370845950

Go testing 包的基准测试非压测工具：单 goroutine 顺序执行，不模拟并发、不统计 QPS/延迟；-bench 仅测函数性能，绕过网络栈与真实链路，适合算法优化而非 HTTP 服务压测。

Go 自带的 testing 包能做基准测试，但不是压测工具——它单 goroutine 顺序执行、不模拟并发请求、不统计 QPS/延迟分布。真要压测 HTTP 服务，得自己搭或用现成工具（比如 hey、wrk），Go 标准库不提供开箱即用的压力测试框架。

用 go test -bench 测的是函数性能，不是服务吞吐

go test -bench 的本质是反复调用一个函数（如 BenchmarkParseJSON），测量其平均耗时和内存分配。它不建立网络连接，不发 HTTP 请求，也不控制并发数或持续时间。

• 适合场景：优化算法、序列化逻辑、缓存命中路径等纯计算或本地 I/O 操作
• 不适合场景：测 http.Handler 响应延迟、查数据库接口的并发承载力、观察 GC 对长连接的影响
• 典型误用：写个 BenchmarkHTTPHandler，里面用 httptest.NewRecorder() 调用 handler —— 这测的是 handler 内部逻辑，绕过了 net/http 服务器栈、TLS、TCP 握手、反向代理等真实链路

自己写 HTTP 压测工具：核心是控制并发 + 计时 + 收集指标

真正压测 HTTP 服务，需要启动多个 goroutine 并发发请求，记录每个请求的开始/结束时间，并聚合统计。关键点不在“发请求”，而在“怎么管住并发节奏”和“怎么避免统计失真”。

• 别用 for i := 0; i —— 这会瞬间创建 1000 个 goroutine，可能打爆目标服务或本机文件描述符
• 用 semaphore 或 channel 控制并发数，例如：

  sem := make(chan struct{}, 10) // 限制 10 并发
  for i := 0; i < 1000; i++ {
      sem <- struct{}{}
      go func() {
          defer func() { <-sem }()
          // 发请求、计时、存结果
      }()
  }

• 每次请求必须用独立的 *http.Client 或复用带超时的 client，避免连接池阻塞；禁用默认重定向：

  client := &http.Client{
      Timeout: 5 * time.Second,
      Transport: &http.Transport{
          MaxIdleConns:        100,
          MaxIdleConnsPerHost: 100,
      },
  }
  req, _ := http.NewRequest("GET", "http://localhost:8080/api", nil)
  req.Close = true // 避免 keep-alive 干扰单请求计时

用 hey 替代手写：更贴近生产环境的真实压力

95% 的 HTTP 服务压测，直接用 hey（Go 写的命令行工具）比手写更可靠——它内置连接复用、动态并发调节、详细的 p90/p95 延迟直方图、失败率统计，且行为可复现。

• 安装：go install github.com/rakyll/hey@latest
• 基础压测：hey -n 10000 -c 100 http://localhost:8080/health（1 万请求，100 并发）
• 带 body 的 POST：hey -m POST -d '{"id":1}' -H "Content-Type: application/json" -n 1000 -c 50 http://localhost:8080/api
• 注意点：默认启用 keep-alive，若想测“每次新建连接”的场景，加 -disable-keepalive；目标服务日志里看到大量 connection reset，大概率是服务端 net.Listen 的 backlog 太小或 ulimit 限制过低

压测不是跑通就行，重点在观察服务在不同负载下的拐点：CPU 何时打满、GC 频次是否突增、慢查询是否出现、连接池是否耗尽。这些信号藏在指标里，不在“QPS 数字”本身。