Go testing.B.SetParallelism 提高 IO 型并行基准吞吐的配置方法

我在给带等待时间的客户端操作写基准时，最容易误判的一点是：RunParallel 的默认并发度不是“尽可能多的请求”。它通常按 GOMAXPROCS 创建并行 worker；如果被测任务大部分时间在等待 IO，CPU 还很空闲，结果就可能低估吞吐。这个场景可以在 RunParallel 前调用 SetParallelism(p)，让 worker 数按 p × GOMAXPROCS 增长。

官方地址：https://pkg.go.dev/testing#B.SetParallelism

实用做法是先用默认值建立基线，再只增加一个并发档位。若 IO 型基准在 1×、2×、4×之间吞吐上升而 CPU 仍有余量，才有理由继续放大；一旦等待、错误或外部服务排队变成主成本，继续加倍只会测到依赖的瓶颈。

先判断 RunParallel 是否真的受 IO 等待限制

SetParallelism 的价值在于模拟更多同时在途的操作，而不是把计算循环“加速”。例如一个 worker 每次都等待连接、文件或远端响应，CPU 只负责准备参数和处理结果，这类基准才有讨论额外并发度的意义。若核心工作是排序、哈希或压缩，默认并发度通常更接近机器可用执行资源，盲目放大反而会引入调度竞争。

代码中把设置放在 RunParallel 之前，并让每个 worker 持有自己的缓冲区。示例用一个抽象的 doIO 表示待测操作，避免把某个真实服务误当成运行证据：

func BenchmarkIOPath(b *testing.B) {
    // 每个 worker 独立持有缓冲区，避免基准被共享写入锁拖偏。
    b.SetParallelism(2)
    b.RunParallel(func(pb *testing.PB) {
        buf := make([]byte, 4

如果机器的 GOMAXPROCS 是 8，SetParallelism(2) 的目标 worker 数就是约 16，而不是固定 2 个。这个倍数关系正是调参时最容易漏看的地方。

用少量并发档位找出外部依赖的承载边界

我更愿意把参数当成实验分组，而不是直接写成一个很大的常数。先执行默认基线，再尝试 2 和 4；若测试环境的连接池或被测服务有明确上限，就让档位不超过那个上限。常见命令可以这样写：

# 先跑基线，再用 -benchtime 固定观察窗口，便于比较同一基准
go test -run '^$' -bench 'BenchmarkIOPath$' -benchmem -benchtime=5s

# 只改变代码里的 SetParallelism 倍数，其他参数保持不变
go test -run '^$' -bench 'BenchmarkIOPath$' -benchmem -count=3

看结果时不要只盯着 ns/op。对 IO 型场景，还要记录每秒完成量、错误数、连接池等待和被测端排队。如果吞吐不再增加但延迟继续上升，说明并发已经越过有效区间；如果 p 小于 1，官方实现不会改变并行度，也不应把它当成关闭并行的开关。

常见问题

SetParallelism 会改变 go test 的 CPU 数吗？

不会。它只为当前 B.RunParallel 设置 worker 倍数，GOMAXPROCS 和进程调度规则仍由运行环境决定。

CPU 密集型基准也应该设置较大的 p 吗？

通常不应该。CPU 密集型任务放大并发容易增加调度和缓存竞争，先用默认值或 -cpu 维度做对比更容易解释。

为什么增大 p 后吞吐反而下降？

常见原因是连接池、远端服务、磁盘队列或限流器先达到容量；此时测到的是排队成本，应降低档位并单独观察等待指标。

最终的配置原则很朴素：用默认并行度做基线，只为确实存在 IO 等待的基准增加倍数，把 p × GOMAXPROCS 换算成真实 worker 数，再用依赖容量和延迟曲线确认边界。这样得到的结论才是可复用的基准设计，而不是一个脱离环境的“推荐数字”。