新服务器上线前，你是不是也这样想过：
“配置应该够了吧？”“优化做完了，应该快了吧？”“并发应该能扛住吧？”
全是“应该”。万一不应该呢？
我见过太多人，服务器买回来、优化做完、业务上线，然后等着用户来验证——用户一多，崩了。这时候才想起来问：到底能扛多少并发？磁盘够不够快？网络会不会是瓶颈？
别猜，测一下就知道。
先搞清楚：你要测什么？
服务器性能不是单一指标，是几个维度的总和：
- CPU：计算能力够不够，密集计算会不会卡死
- 内存：读写速度，延迟高不高
- 磁盘：读写快不快，随机读写（IOPS）跟不跟得上
- 网络：带宽够不够，延迟高不高，并发连接能不能撑住
- 整体压测：模拟真实用户请求，看服务器能扛多少并发，响应时间多少
每个维度有对应的工具。下面一个个说。
CPU和内存：用sysbench
sysbench 是个全能选手，测CPU、内存、线程、数据库都行。用法也简单。
测CPU：算20000个素数，看用时多少
bash
sysbench cpu --cpu-max-prime=20000 run
输出里有个 total time，就是耗时。同样配置的机器，时间越短说明CPU越快。
测内存：读写测试
bash
sysbench memory --memory-block-size=1M --memory-total-size=10G run
看吞吐量（MiB/sec），数值越高越好。
如果想看高负载下系统稳不稳，可以用 stress：
bash
stress --cpu 4 --timeout 60
四个CPU核心跑满一分钟，看服务器会不会死机、温度会不会爆。一般用于稳定性测试，不是测性能。
磁盘：fio 是王者
磁盘性能不能光看顺序读写，你跑数据库、网站，全是随机小文件，这时候看的是 IOPS（每秒读写次数）。
fio 可以模拟各种场景。下面这个命令测的是 75% 读、25% 写、4K 随机访问，模拟典型数据库负载：
bash
fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --bs=4k --iodepth=64 --size=1G --readwrite=randrw --rwmixread=75
跑完看几个关键值：
read: IOPS=每秒读次数write: IOPS=每秒写次数clat (usec)完成延迟，数值越小越好
反常识数据：很多人只看顺序读写（厂商宣传的 3500MB/s），但真实业务里，4K 随机 IOPS 才是决定你数据库快不快的指标。一块家用 SSD 顺序读可能很快，随机 IOPS 可能只有几千，而企业级能到几万甚至几十万。
不想折腾 fio，可以用 hdparm 快速看一眼：
bash
hdparm -t /dev/sda
这个测的是顺序读，仅供参考。
网络：iperf3 是标准
想测两台机器之间的带宽？iperf3。
服务端（假设 IP 是 192.168.1.100）：
bash
iperf3 -s
客户端：
bash
iperf3 -c 192.168.1.100
跑完会看到带宽（bits/sec）和重传率。重传率太高说明网络不稳定。
想测延迟？ping 就行，但 ping 只测 ICMP，更接近真实情况的是测 TCP 握手时间，用 curl -w：
bash
curl -o /dev/null -s -w 'TCP handshake: %{time_connect}s\n' https://你的网站
这个能看到从发起连接到 TCP 握手完成的时间，比 ping 更贴近用户真实体验。
整体压测：模拟真实用户
前面都是测单点，但用户访问是整套流程：DNS解析、TCP连接、发送请求、服务器处理、返回数据。整体压测才能反映真实能扛多少并发。
ab（Apache Bench）：最简单，系统一般自带。
bash
ab -n 1000 -c 100 http://你的网站/
-n 总请求数，-c 并发数。跑完看：
Requests per second：每秒能处理多少请求（吞吐量）Time per request：平均每个请求耗时Failed requests：失败的，如果有，说明扛不住
但 ab 有局限，它不能模拟复杂的请求流程，而且压测端本身可能成为瓶颈。
wrk：更现代，性能更高。
bash
wrk -t12 -c400 -d30s http://你的网站/
-t 线程数，-c 连接数，-d 持续时间。输出更丰富，有延迟分布：50%、75%、90%、99% 分位的响应时间。
siege：模拟多用户访问，支持带参数的 URL。
bash
siege -c 100 -t 60s http://你的网站/
-c 并发用户数，-t 持续时间。跑完看可用性（Availability）和响应时间。
怎么读懂测试结果
一堆数字出来，怎么看？
吞吐量（Requests per second）：每秒能处理多少请求。同样配置，这个越高越好。
响应时间：看平均值，更要看高分段（90%、99%）。平均值 100ms，但 99 分位 500ms，说明有一部分用户很卡。
错误率：理想情况是 0%。如果压测时出现错误，说明已经到极限了。
系统资源变化：压测的时候开着 top、iostat 看，如果 CPU 先到 100%，瓶颈在 CPU；如果磁盘 I/O 先爆，瓶颈在磁盘；如果带宽先打满，瓶颈在网络。
实战案例：压测一个 WordPress 网站
之前帮朋友压过他的 WordPress 网站，2核4G 配置，Nginx + PHP-FPM + MySQL，没开任何缓存。
先用 ab 跑 100 并发：
bash
ab -n 1000 -c 100 http://他的网站/
结果：RPS 只有 45，平均响应时间 2.2 秒，失败率 0%，但 CPU 已经 90% 了。
看监控，发现 PHP-FPM 进程数暴增，MySQL 查询很慢。查慢查询日志，发现某个插件在首页做了 20 多次数据库查询。
优化方案：装 Redis 做对象缓存，把 SQL 查询结果缓存起来；再加个页面缓存插件，静态页面直接存 HTML。
优化后再压：
bash
ab -n 1000 -c 100 http://他的网站/
RPS 直接到 320，平均响应时间 0.3 秒，CPU 降到 30%。
数字会说话。优化前靠猜，优化后靠测，差距就在这。
压测注意事项（别把自己打崩了）
第一，别在生产环境压测。除非你想被用户骂。实在要测，选低峰期，且随时准备停止。
第二，压测工具所在机器要有足够资源。你从一台 1核1G 的机器压高性能服务器，先崩的可能是压测端。
第三，逐步增加并发。别一上来就 1000 并发，先 10、50、100，慢慢加上去，找到临界点。
第四，监控被压服务器的资源。CPU、内存、磁盘 I/O、网络，哪个先到瓶颈，哪个就是你要优化的地方。
第五，多次测试取平均。网络有波动，跑三次取平均值更可靠。
数据不说谎
很多人买完服务器、做完优化，心里没底，全靠“感觉”。感觉快，感觉能扛住。
但感觉会骗人，数据不会。
下次再有人问你这服务器行不行，别拍胸脯，把压测报告甩他脸上：
“RPS 5000，99 分位响应时间 200ms，错误率 0%，你自己看。”
比说一万句“没问题”都管用。
你的服务器到底行不行？找个工具测一下，答案马上就出来。