很多团队把业务迁到云上后，默认弹性伸缩会自动解决性能问题，但结果常常不如预期。云环境的网络拓扑更复杂，虚拟机规格、云盘 IOPS、负载均衡的连接数、数据库的最大连接数，每一项都可能成为瓶颈。与其等线上出故障再排查，不如在上线前做一轮阿里云性能测试，把风险提前摸清。
我们之前服务过一家做在线教育的客户。他们的直播课报名系统日常运行平稳，但每次大型活动推送后，接口响应时间会从200毫秒涨到5秒以上。团队一开始怀疑是应用代码，改了两轮，效果都不明显。后来我们做了完整的压测和监控分析，问题落在数据库连接池配置和云盘性能上限上。性能问题很少只有一个原因，靠系统化的测试定位，比凭经验猜测可靠得多。
压测前要准备什么
把流量打上去不等于压测完成。开始之前，有几件事要先定下来。
- 业务目标：把验收指标写成具体数字，比如核心下单接口在峰值 QPS 3000 时，P99 响应时间不超过 800 毫秒。指标没写下来，测完就很难判断通过还是不通过。
- 测试范围：先决定是压单个接口，还是压完整业务链路。如果链路上有第三方依赖，要提前确认它们是否参与测试，或者能否模拟。
- 环境选择：预发环境的规格最好和生产一致。规格不同，测出来的数字就只能参考趋势，很难直接拿来预估线上容量。
- 数据准备：测试数据量要接近生产，特别是数据库的表行数和索引情况。数据量太小，慢查询往往测不出来，等到线上才暴露。
在阿里云上，压测机可以按需拉起，测完释放，成本比较好控制。但压测机自己不能先成为瓶颈。压测节点的带宽、CPU 和内存要单独监控。如果压测机已经跑满，得出的“上限”其实是压测机的上限，并不是被测系统的上限。
常用的测试类型怎么选
性能测试大致分为五类，每类回答的问题不一样。
- 基准测试：在单用户或低并发下测量基础性能，作为后面所有对比的参照。没有基线，后面的数字就无从比较。
- 负载测试：逐步加并发，看系统在预期负载下的表现。
- 压力测试：持续加压，直到出现性能拐点或错误率上升，用来找容量上限。
- 稳定性测试：在一定负载下连续运行，比如跑12小时，观察内存泄漏、连接耗尽和日志膨胀。这类问题短时间内通常看不出来。
- 突发流量测试：模拟秒杀或活动开始瞬间的流量尖峰，检验限流、排队和降级策略是否真的生效。
选哪种，取决于上线前最担心什么。只是常规版本发布，负载测试加基准对比一般够用。要备战大促，压力测试和突发流量测试更关键。
一个完整的压测案例
下面用一个电商商品详情接口说明从设计到分析的过程。
先测基线
在 10 个并发下，接口平均响应时间为 45 毫秒，P99 为 120 毫秒，CPU 利用率约 20%。这组数字是后续所有对比的起点。
阶梯加压
我们每 5 分钟把并发加 100。并发加到 400 左右时，平均响应时间开始明显上升，P99 达到 600 毫秒，但错误率仍是 0。加到 500 并发时，错误率突然跳到 3%，报错为连接超时。
找瓶颈
结合应用监控和数据库监控，问题出在两处。一是应用服务器的数据库连接池最大值只设了 50，高并发下大量请求排队等连接。二是商品库存查询走了一条没有命中索引的 SQL，单次查询扫描行数超过两万。我们修了索引，把连接池调到合理值，同样的压力下错误率降到 0，P99 回落到 150 毫秒以内。
改完再测一遍
优化后，我们重新跑了完整的阶梯压测，又做了 30 分钟的稳定性测试，确认没有新瓶颈冒出来。报告里记录了环境配置、测试脚本版本、各阶段指标和结论。下次版本迭代时，可以直接拿来对比。
阿里云环境下容易漏掉的几点
- 云盘性能上限：不同规格的云盘有各自的 IOPS 和吞吐量上限。数据库或日志写入密集的应用，往往先撞到这里。压测时要同时看磁盘指标，不能只盯 CPU。
- 负载均衡连接数：监听器的并发连接数和新建连接速率都有限制。压测前查一下配额，压的时候看是否已经触发。
- 实例突发性能：部分共享型实例有 CPU 积分机制，长时间高负载后性能会回落。测试时间要足够长，否则这类问题暴露不出来。
- 安全与合规：对外部署的压测任务，要提前和平台、安全团队沟通。否则压测流量可能被当成攻击拦截，或者触发告警。同时，压测行为也要符合云服务的使用条款。
压测结果怎么留存
阿里云性能测试的关键，不在于工具多复杂，而在于目标是否写清楚、环境是否可信、分析是否扎实。每次压测都保留完整的数据和结论，时间长了，就是团队自己的性能基线。上线前心里会踏实很多，因为这些数字都是实测出来的。
