升级实例后，CPU 使用率下降了，服务却不一定更快：瓶颈可能在磁盘、网络、数据库连接或应用锁等待。要判断升级是否解决了问题，应先做计算实例规格升级前的性能基准测试，留下可复查的起点。测试对象、负载和观测方式一致，升级前后的差异才有解释力。
先确定要比较什么
不要只看平均 CPU。根据服务目标，至少记录请求吞吐量、响应时间的中位数与 P95/P99、错误率，以及 CPU、内存、磁盘和网络指标。尾延迟能显示少数慢请求是否恶化；磁盘读写延迟或网络丢包等指标，则有助于排除“换了更大规格但瓶颈仍在别处”的情况。
同时记录实例规格、操作系统与软件版本、并发数、数据量、缓存状态、测试时间和后台任务。基线指标要覆盖正常负载；如果流量有明显峰谷，应选取有代表性的时段，不能拿低谷数据与高峰数据直接比较。
按可复现的顺序执行
- 准备环境。优先在隔离环境或可回收的副本上测试，确认不会向生产服务写入不该写的数据。若只能在生产环境观察，应使用低风险、可限流的负载，并先约定停止条件。
- 固定负载。选定一组能代表实际请求的操作，记录并发量、持续时间和数据规模。测试工具、参数与输入应留档；数据库场景可考虑使用与实际查询类型相符的基准工具，不能只凭合成计算负载推断整套应用表现。
- 采集基线。先观察一段时间确认服务状态稳定，再运行负载并同步记录应用与系统指标。短测适合发现明显瓶颈；若要判断缓存、后台任务或持续负载影响，可延长到几十分钟或更久，具体取决于业务周期和风险。
- 升级后复测。在尽量相同的环境、参数和时段重放测试。测试前确认软件配置、存储类型、网络路径等没有同时改变；否则需要把这些变化单独标注，避免把多项改动误认为规格收益。
- 保存证据并设回退条件。归档原始监控、测试命令与参数、变更时间、规格信息和结果摘要。预先写明可接受的延迟、错误率和资源余量阈值；若升级后触发阈值或关键指标持续变差，按既定流程恢复原规格并复测。
比较结果时看瓶颈是否转移
比较时把同一指标放在一起看，并注明测试时长与环境差异。吞吐提升但 P99 延迟明显上升，可能意味着排队或共享资源竞争；CPU 下降而磁盘延迟不变，说明存储路径仍可能限制性能。内存更充足也不自动等于服务变快，应用是否能利用额外内存、是否存在配置上限，都需要结合实际检查。
对于磁盘密集型任务，可用 fio 在安全的测试盘上评估读写模式、队列深度和延迟；不要直接对承载真实数据的设备做可能覆盖数据的写测试。数据库如 PostgreSQL，可在测试库中用 pgbench 生成可重复负载，但其结果只代表所设定的事务与数据规模，不能替代真实查询分析。工具读数应与应用监控交叉核对。
这套计算实例规格升级前的性能基准测试记录还应包含测试失败、被中断或结果异常的情况，而不只是“升级成功”。如果新规格表现变好，也要确认提升是否超过同一规格重复测试时的波动；差异很小时，可增加重复轮次或延长观测，而不是直接下结论。
常见问题
只测一次够不够？
通常不够。负载、缓存和后台任务会造成波动，建议至少重复几轮，并保留每轮结果；测试成本或风险较高时，先缩小范围再决定是否增加轮次。
升级前后能否使用不同测试工具？
不建议。工具和参数变化会引入新的变量。确需更换时，应在升级前后都用新旧工具做交叉验证，并说明口径差异。
什么时候可以认为升级有效？
当关键业务指标达到预定目标、没有新增错误或明显资源瓶颈，且结果可重复时，才有较充分依据。计算实例规格升级前的性能基准测试及复测记录，能帮助团队判断收益、解释异常，并在需要时追溯与回退。
