Go 服务的性能取决于工作负载、数据规模、依赖项和硬件。QPS 和延迟数据只有结合可复现的测试说明才有意义。本规划指南解释应测量哪些内容以及如何审核优化方案；不承诺任何吞吐量或响应时间。
先定义工作负载，再设定目标
| 输入 | 在测试计划中记录 | 重要原因 |
|---|---|---|
| 流量 | 请求组合、并发用户数、突发流量和测试持续时间 | 单个缓存端点无法代表整个产品 |
| 数据 | 数据集大小、查询形态和缓存状态 | 较小或已预热的数据集可能掩盖数据库限制 |
| 环境 | CPU、内存、网络和外部依赖项 | 结果无法在不同环境之间原样迁移 |
| 结果 | 百分位延迟、错误率、吞吐量和资源使用情况 | 平均延迟会掩盖慢请求和失败 |
测量瓶颈
使用性能分析检查 CPU、内存分配和阻塞情况，并通过跟踪分析请求各环节耗时。即使应用 CPU 使用率较低，数据库连接等待、慢查询和外部 API 也可能占据主要耗时。性能分析会产生开销，因此应记录其使用情况，并在一致的条件下进行比较。参见官方 Go 诊断指南。
针对基线一次应用一项变更
可能的变更包括查询索引、受限并发、上下文截止时间、连接池调优或缓存。说明预期机制、失效规则和故障行为。使用相同的工作负载，将每项变更与基线进行比较；只有当预期行为和性能同时得到改善时，才保留该变更。
申请后端性能评审
准备受影响的端点、观测到的流量、延迟和错误样本、数据库规模、托管限制以及任何既有测试方法。从跟踪数据中删除凭据和个人数据。了解后端和业务系统开发，或发送性能评审简介。在实施前就可衡量的验收标准和回滚计划达成一致。