选云服务器时，不少人主要看配置单和价格。上线后却遇到页面卡顿、接口超时，高峰期直接挂掉，这种情况很常见。配置单上的数字是厂商给出的理论值，业务跑起来是什么表现，要靠云服务器性能测试才能知道。下面说说测什么、怎么测，以及结果怎么读。
一、为什么要做云服务器性能测试
厂商写的 CPU 核数、内存大小、带宽峰值，都是上限。实际能拿到多少，取决于宿主机当前负载、虚拟化开销、磁盘类型和网络抖动。同样是 4 核 8G，换个可用区或机型，表现可能差距不小。
测试的用处主要有这几个：
- 上线前确认机器能扛住预估流量，别等流量来了才临时扩容
- 对比不同机型和厂商，选型时手里有数据可看
- 给容量规划和弹性伸缩的阈值提供依据
- 每次版本迭代后跑一遍，和之前的基线对比，性能回退能及时发现
二、核心测试指标
测之前先定好要看哪些指标。没有目标的测试，很容易跑了一堆工具，最后说不清结论。
- 计算：先看 CPU 利用率，再看单核和多核得分。上下文切换次数突然升高，通常说明线程数设置或并发模型有问题。
- 内存：关注内存带宽、分配延迟，以及 Swap 是否被用上。一旦开始走 Swap，接口延迟会明显抖动。
- 磁盘：随机读写 IOPS、顺序吞吐（MB/s）和 I/O 延迟。数据库、日志密集型业务，IOPS 和延迟通常比吞吐更关键。
- 网络：内网与公网带宽、丢包率、连接建立耗时，以及 PPS。小包多的场景里，PPS 往往比带宽先成为瓶颈。
- 应用：QPS、TPS、P95 和 P99 响应时间、错误率。
应用层指标最贴近用户感受。硬件跑分再好看，P99 要是两秒，用户照样觉得慢。底层指标和应用指标要放在一起看，只看一边很容易误判。
三、测试方法与工具
1. 基础资源测试
用 sysbench 测 CPU 和内存，用 fio 测磁盘，用 iperf3 测网络吞吐。这几个工具开源、用得广，结果可以复现，适合拿来做基线。
测 4K 随机读写，可以用下面这条命令：
fio –name=randrw –ioengine=libaio –rw=randrw –bs=4k –direct=1 –size=1G –numjobs=4 –runtime=60 –group_reporting
这里的 direct=1 表示绕过系统页缓存，测出来的结果更接近磁盘真实能力。如果去掉它，页缓存会把数字抬高，拿去做选型就会偏乐观。
2. 压力与负载测试
单项能力只能说明机器各部分的水平，并发场景下的表现还要靠压测。常用工具有 JMeter、wrk、Locust。建议从低并发开始阶梯式加压，每个台阶停留一段时间，逐步加到目标值的 1.5 倍左右。盯住两个位置：响应时间开始明显上翘的拐点，以及错误率开始上升的点。它们之内的范围，才是系统实际的承载能力。
3. 稳定性测试
不少机器短时间压测很稳，跑到第二天性能就往下掉。所以还需要做 8 到 24 小时的持续负载测试，重点看内存是否缓慢上涨、磁盘会不会被写满、性能曲线是否平稳。
四、一个排查的例子
某电商团队计划把促销活动部署到一台 8 核 16G 的云服务器上，预估峰值 QPS 为 1200。上线前他们按上面的流程测了一遍，过程大致如下：
- sysbench 测下来 CPU 多线程表现正常，但磁盘随机写 IOPS 只有标称值的 40%
- 用 wrk 压商品详情接口，并发 300 时 P99 到了 1.8 秒，距离 500 毫秒的目标差得很远
- 继续排查，发现日志同步写盘会阻塞业务线程
后来团队把日志改成异步写入，磁盘也从普通云盘换成了 SSD 云盘。同样的并发下，P99 降到 380 毫秒，QPS 稳定在 1500 左右，活动可以正常承接。
这个例子里，问题并不出在某一项指标上。只看 CPU 会以为机器没问题，只看带宽也找不到原因。分层测完，再结合应用指标一起看，才定位到了具体环节。
五、测试结果怎么看
拿到数据后，可以先问三件事：
- 是否达到业务目标，比如 QPS 和响应时间有没有到线
- 资源利用率是否健康。CPU 长期超过 80%，一般就该考虑留出余量或扩容
- 多次测试的结果稳不稳。波动大时，多半是宿主机资源被其他租户争抢
还有一点容易忽略：测试环境要尽量和生产保持一致，包括系统版本、内核参数、中间件配置和网络拓扑。环境差得太多，测出来的结论和线上对不上，这次测试基本等于白做。
六、小结
云服务器性能测试的步骤并不复杂，难点在于先想清楚要验证什么，选对指标，再把流程完整跑下来。建议把它固定进上线流程，留存一份基线数据，并定期复测。这样线上出问题的概率会低很多，后面做成本优化和架构调整时，也有数据可以依据。
