3. 性能指标定义：吞吐量(QPS)、延迟(P50/P99/P999)、错误率、资源利用率(CPU/内存/IO)

在 CI/CD 集成中，对 Go 服务进行性能回归测试的第一步是建立统一、可量化的指标定义。没有明确的指标，调优将失去方向，回归对比也将失去意义。本章将定义四个核心维度：吞吐量、延迟、错误率和资源利用率，并解释它们在 Go 服务上下文中的具体含义与采集方式。

3.1 吞吐量 (QPS / TPS)

吞吐量衡量服务在单位时间内能处理的请求数量，通常以 QPS (Queries Per Second) 或 TPS (Transactions Per Second) 表示。在 Go 服务中，这直接反映了并发处理能力和系统容量。

3.2 延迟 (Latency: P50 / P99 / P999)

延迟是用户体验的核心指标。仅看平均延迟 (Avg) 容易掩盖长尾问题，因此必须使用百分位延迟。在 Go 服务中，推荐关注 P50、P99 和 P999。

• P50 (中位数延迟)：50% 的请求在此时间内完成。反映大多数用户的体验。
• P99 (99 分位延迟)：99% 的请求在此时间内完成。用于衡量系统在高负载下的稳定性，通常作为 SLO 的关键指标。
• P999 (99.9 分位延迟)：最慢的 0.1% 请求。用于排查极端慢速请求，通常与 GC 停顿、锁竞争或网络抖动相关。

import "github.com/prometheus/client_golang/prometheus"

var requestDuration = prometheus.NewHistogramVec(
    prometheus.HistogramOpts{
        Name:    "http_request_duration_seconds",
        Help:    "HTTP request latency distributions.",
        Buckets: prometheus.DefBuckets, // 默认桶: .005, .01, .025, .05, .1, .25, .5, 1, 2.5, 5, 10
    },
    []string{"method", "path"},
)

3.3 错误率 (Error Rate)

错误率是服务健康度的直接体现。在性能回归测试中，错误率不应仅统计 HTTP 5xx，还应包括业务逻辑错误和超时错误。

在 CI/CD 回归测试中，通常设定 错误率阈值 ≤ 0.1%（包含所有非预期错误）。如果新版本引入的代码导致错误率上升，即使 QPS 达标，也应判定为回归失败。

3.4 资源利用率 (CPU / 内存 / IO)

资源利用率指标用于判断性能瓶颈所在。在 Go 服务中，这三个维度具有鲜明的语言特性。

• CPU 利用率：Go 的 Goroutine 调度和 GC 都会消耗 CPU。高 CPU 通常意味着计算密集或 GC 频繁。
• 内存利用率：关注 Heap Inuse 和 GC 频率。Go 的内存模型决定了堆内存的波动性，应关注 RSS 峰值 和 GC 暂停时间。
• IO 利用率：包括网络 IO 和磁盘 IO。对于 Go 服务，网络 IO 通常通过 net/http 的连接池体现；磁盘 IO 则多见于日志写入和数据库操作。

import "runtime"

var m runtime.MemStats
runtime.ReadMemStats(&m)
fmt.Printf("Alloc = %v MiB", m.Alloc / 1024 / 1024)
fmt.Printf("TotalAlloc = %v MiB", m.TotalAlloc / 1024 / 1024)
fmt.Printf("Sys = %v MiB", m.Sys / 1024 / 1024)
fmt.Printf("NumGC = %v\n", m.NumGC)

3.5 指标间的权衡与关联

四个指标并非孤立存在，它们之间存在典型的跷跷板效应。在 CI/CD 回归测试中，必须综合评估，不能只看单一指标。

• QPS vs. 延迟：当 QPS 接近系统极限时，延迟会急剧上升（拐点效应）。
• QPS vs. 错误率：过高的 QPS 可能导致连接池耗尽、内存溢出，从而引发错误率飙升。
• 延迟 vs. 资源利用率：CPU 或 IO 成为瓶颈时，延迟会线性增加。
• 内存 vs. GC 暂停：内存分配速率过高会导致 GC 频繁，进而增加 P99 延迟。

3.6 指标采集与 CI/CD 集成建议

在 CI/CD 流水线中，建议使用以下工具链采集上述指标：