买云服务器时，大多数人盯着配置表看：几核、多少内存、带宽写了多少兆。等业务上线，才发现页面打开慢，接口动不动超时。其实无论下单前还是下单后，花一两个小时做一轮云服务器测速，大部分性能问题都能提前看出来。这篇文章讲三件事：测哪些指标，用哪几个工具，结果怎么读。
配置表不能直接当结论
同样是2核4G，放在不同机房、不同宿主机上，跑出来的结果可能差很远。超售比例高的机器，业务高峰时CPU资源会被挤掉一部分。宣传页上写的“百兆带宽”，只是出口的理论上限，用户访问时能拿到多少，还要看网络高峰期、跨运营商互联，以及线路是不是绕远路。
测速要解决的，是用数据代替感觉。具体可以问自己三个问题：这台机器离目标用户够不够近，磁盘和CPU扛不扛得住业务，连续跑几天会不会出状况。三个问题都有了答案，选型基本就不会踩坑。
需要盯的5个指标
- 网络延迟（Ping）：一次数据包往返所花的毫秒数。网站和接口服务对它最敏感，延迟高，首屏就慢。
- 丢包率：丢失的数据包占比。超过1%时，TCP重传会明显拖慢传输，视频和实时通信类业务感受最直接。
- 下载与上传带宽：单位通常是Mbps。下载影响用户拿页面和文件的速度，上传影响推流、备份和文件回传，两个方向要分开看。
- 磁盘IO性能：随机读写的IOPS和吞吐量。数据库、日志写入密集的服务最依赖它，很多被归为“程序卡”的问题，其实是磁盘跟不上。
- CPU与内存性能：单核、多核运算能力，以及内存读写速度。单看绝对数字意义不大，要用同一个基准工具跑出分数，才方便横向比较。
三类工具怎么用
网络：ping、mtr 和带宽测试
ping 用来看基础延迟和丢包，建议跑100次左右。单次结果波动大，样本太少说明不了问题。mtr 会逐跳列出路由，哪一段延迟突然拔高、哪一跳开始丢包，一眼就能看出来，比只看总延迟有用得多。带宽可以用 speedtest-cli 测，也可以在服务器上用 curl 下载一个已知大小的文件，按下载时长估算速度。
常用命令大致是这几条：
- ping -c 100 你的服务器IP，统计平均延迟和丢包率
- mtr -rwc 100 你的服务器IP，生成路由报告，记下延迟突变的那一跳
- curl -o /dev/null 测速文件地址，观察下载速度（测速文件最好选离目标用户近的节点）
磁盘：fio
fio 是 Linux 上最常用的磁盘IO测试工具。测随机读写时，块大小用4K更接近数据库和日志的真实负载，队列深度要设成和业务并发接近的值，否则结果会偏高或偏低。跑之前先确认测试对象是空盘或专门的测试盘，别直接压测正在用的数据盘，写坏了没法回头。
综合性能：sysbench 与 UnixBench
sysbench 可以分别测CPU、内存和数据库读写，同一套参数在不同机器上跑，差异一目了然，做横向对比很合适。UnixBench 给出综合分，适合快速判断机器大概是什么档次。同一台机器在不同时段分数会有波动，跑三到五次取平均，结论才站得住。
一个实际案例
某电商小团队的用户主要在广州。他们原本打算选杭州的一台4核8G云服务器，理由是价格低、配置高。上线前先做了一轮测速：从广州本地 ping，平均延迟约42毫秒，晚高峰丢包率超过2%，mtr 显示跨网段时有明显绕行。
接着他们在广州节点买了同配置的机器，跑同样的测试。平均延迟降到8毫秒左右，丢包率稳定在0.1%以下。两台机器的磁盘测试结果接近，CPU分数也差不多。
这个结果说明，用户集中在华南的业务，机房位置对体验的影响远比配置差异大。团队最后选了广州节点，页面首屏时间明显缩短。测速看的不只是数字，还要和用户分布对得上，才知道哪个指标该优先。
测完之后怎么读结果
拿到数据，先按业务类型排优先级。网站和API服务先看延迟和丢包；数据库重点看磁盘IOPS和内存；文件分发、视频类服务盯住带宽和上传速度。
有几件事要留意。测试最好分时段进行，至少覆盖一个工作日的早、中、晚，只测一次很容易得出片面结论。每次测试的命令和参数保持一致，前后数据才能对比。如果实测结果和厂商宣传差距很大，把测试记录留好，拿去和服务商沟通，或者申请更换节点，比凭感觉争论有用。
整体思路很简单：先用 ping 和 mtr 把网络摸清，再用 fio 和 sysbench 检查磁盘与计算能力，最后对照用户所在地域做决定。大多数选型上的坑，在下单前就能避开。
