"这台服务器能撑多少人访问？"——这个问题的答案不能靠猜，要用数据说话。

压测能帮你：知道性能上限、发现瓶颈在哪、验证优化效果、避免上线就崩。

这篇讲 CPU、内存、磁盘、网络、Web 五个维度的测试工具和判读方法。

测完发现不够就该升级或优化。财富云计算 的云服务器支持按需升级；内网服务、游戏服务端可选 NAT 型（无独立公网 IP，价格比带独立 IP 机型省一半以上）。

一、压测前的准备

1）明确目标

2）测试环境隔离

• 不要在生产环境压测（会影响真实用户）
• 压测机和被测机分开（避免压测机本身成为瓶颈）
• 记录测试前的基线数据

3）监控要同步开着

压测时同时观察：

# 终端 1：压测
ab -n 10000 -c 100 http://target/

# 终端 2：资源
top
# 或
htop

# 终端 3：连接和带宽
ss -s
iftop

# 终端 4：磁盘
iostat -x 1

同时在看资源才知道瓶颈是什么：CPU 满了？内存没了？磁盘 IO 打满？带宽满了？

二、CPU 性能测试

sysbench（推荐）

apt install sysbench -y

# CPU 测试（计算素数）
sysbench cpu --cpu-max-prime=20000 --threads=4 run

输出关注 events per second，数字越大越好。

对比参考（4 核）：普通云服务器单线程 events/sec 通常在 500~1500，多核线性增长。

简单单核测试

# 计算圆周率（单线程）
time echo "scale=5000; 4*a(1)" | bc -l

多核并行

sysbench cpu --threads=$(nproc) run

判读：

• 多核成绩接近 单核 × 核数 → 正常
• 远低于线性增长 → 可能是共享型 CPU 被限流，或 %st 高

top   # 看 %st（steal），高说明宿主机超卖

三、内存性能测试

# sysbench 内存测试
sysbench memory --memory-block-size=1K --memory-total-size=10G run
sysbench memory --memory-oper=write --memory-total-size=10G run

关注 MiB transferred（吞吐），一般内存带宽在几 GB/s 量级。

更实际的测试是看你的程序在内存不足时的表现，而不是纯带宽。

四、磁盘 IO 测试

dd（粗略）

# 顺序写（注意：一定要加 oflag=direct 绕过缓存，否则测的是内存速度）
dd if=/dev/zero of=/data/test bs=1M count=1024 oflag=direct

# 顺序读
dd if=/data/test of=/dev/null bs=1M iflag=direct

# 清理
rm -f /data/test

参考值：SSD 顺序写通常 200~500 MB/s，HDD 100~200 MB/s。

fio（专业，推荐）

apt install fio -y

# 随机读（最贴近数据库场景）
fio -filename=/data/test -direct=1 -iodepth 1 -thread -rw=randread \
    -ioengine=psync -bs=4k -size=1G -numjobs=1 -runtime=60 \
    -group_reporting -name=randread

# 随机写
fio -filename=/data/test -direct=1 -iodepth 1 -thread -rw=randwrite \
    -ioengine=psync -bs=4k -size=1G -numjobs=1 -runtime=60 \
    -group_reporting -name=randwrite

# 混合随机读写（70% 读 30% 写）
fio -filename=/data/test -direct=1 -iodepth 1 -thread -rw=randrw \
    -rwmixread=70 -ioengine=psync -bs=4k -size=1G -numjobs=1 \
    -runtime=60 -group_reporting -name=randrw

# 高并发 IOPS 测试
fio -filename=/data/test -direct=1 -iodepth 32 -rw=randread \
    -ioengine=libaio -bs=4k -size=1G -numjobs=4 -runtime=60 \
    -group_reporting -name=iops

关键指标：

参考标准：

• 普通云 SSD：4k 随机读 IOPS 3000~10000
• 高性能 NVMe：几万到几十万
• HDD：100~200 IOPS

IOPS 低是数据库慢的常见根因。

五、网络性能测试

带宽测试

# speedtest
apt install speedtest-cli -y
speedtest-cli

# 或用 curl 测下载
curl -o /dev/null https://speed.cloudflare.com/__down?bytes=100000000

两台机器之间测（更准确）

用 iperf3：

# 服务端（被测机）
apt install iperf3 -y
iperf3 -s

# 客户端（压测机）
iperf3 -c 服务器IP -t 30
iperf3 -c 服务器IP -t 30 -P 10       # 10 并发流
iperf3 -c 服务器IP -t 30 -u -b 100M  # UDP 测试

输出：

[ ID] Interval           Transfer     Bitrate         Retr
[  5] 0.00-30.00 sec     1.10 GBytes   315 Mbits/sec  123

Bitrate 就是实际带宽，Retr（重传）多说明网络质量差。

延迟测试

ping -c 100 目标IP
# 看 avg 和 mdev（抖动）

mtr -r -c 100 目标IP
# 看每一跳

六、Web 压测（重点）

Apache Bench（ab，最简单）

apt install apache2-utils -y

# 1000 个请求，50 并发
ab -n 1000 -c 50 http://example.com/

# 开启 Keep-Alive（更贴近真实）
ab -n 1000 -c 50 -k http://example.com/

# POST 请求
ab -n 100 -c 10 -p post.txt -T application/json http://example.com/api

# 带 Header（如 token）
ab -n 100 -c 10 -H "Authorization: Bearer xxx" http://example.com/api

输出解读：

Concurrency Level:      50
Time taken for tests:   20.357 seconds
Complete requests:      1000
Failed requests:        0                    ← 必须关注
Requests per second:    49.12 [#/sec]        ← QPS
Time per request:       1017.850 [ms]        ← 用户感受到的延迟
Time per request:       20.357 [ms] (across all concurrent requests)
Transfer rate:          850.32 [Kbytes/sec]

Percentage of the requests served within a certain time (ms)
  50%    812
  95%   1520
  99%   2104                                  ← P99 很重要
 100%   3120

关键指标：

P99 比平均值重要：平均 100ms 但 P99 是 3 秒，意味着 1% 的用户体验极差。

wrk（更强大，推荐）

apt install wrk -y

# 4 线程，100 并发，持续 30 秒
wrk -t4 -c100 -d30s http://example.com/

# 带脚本（POST、自定义 Header）
wrk -t4 -c100 -d30s -s post.lua http://example.com/api

post.lua 示例：

wrk.method = "POST"
wrk.body   = '{"key":"value"}'
wrk.headers["Content-Type"] = "application/json"

逐步加并发找拐点

for c in 10 50 100 200 500; do
  echo "并发 $c:"
  ab -n 1000 -c $c http://example.com/ 2>/dev/null | grep "Requests per second"
done

典型的曲线：QPS 随并发上升 → 到某个点后趋于平缓甚至下降 → 那个点就是系统的容量上限。

超过拐点后：响应时间暴涨、失败率上升，说明已经过载。

七、数据库压测

# MySQL 自带
mysqlslap --auto-generate-sql --concurrency=50 --iterations=3 --number-of-queries=1000

# sysbench（更专业）
sysbench /usr/share/sysbench/oltp_read_write.lua \
  --mysql-host=localhost --mysql-user=root --mysql-password=xxx \
  --mysql-db=testdb --tables=4 --table-size=100000 \
  prepare

sysbench /usr/share/sysbench/oltp_read_write.lua \
  --mysql-host=localhost --mysql-user=root --mysql-password=xxx \
  --mysql-db=testdb --tables=4 --table-size=100000 \
  --threads=16 --time=60 run

sysbench ... cleanup

关注 transactions（TPS）和 queries（QPS）。

八、压测时同步看的指标

一个终端跑压测，另外几个终端看：

# 资源总览
top
# 关注：%us %sy %wa %st、load average、内存

# 连接状态
ss -s
ss -ant | awk '{print $1}' | sort | uniq -c

# 磁盘 IO
iostat -x 1
# 关注 %util 和 await

# 带宽
iftop -i eth0

# Web 服务自身
# Nginx 错误日志
tail -f /var/log/nginx/error.log
# PHP-FPM 状态
watch -n 1 'curl -s http://127.0.0.1/phpfpm-status | head -20'
# MySQL
mysqladmin -uroot -p status
mysql -e "SHOW PROCESSLIST;"

判断瓶颈：

九、优化前后对比

压测最有价值的用法是验证优化效果：

# 优化前
ab -n 5000 -c 100 http://example.com/ > before.txt

# 做优化（开 OPcache、加索引、加缓存...）

# 优化后
ab -n 5000 -c 100 http://example.com/ > after.txt

# 对比 QPS
grep "Requests per second" before.txt after.txt

常见优化手段的效果量级：

十、注意事项

1）不要在生产环境压测

会导致真实用户访问失败，甚至被云服务商限流。要压就：

• 在测试环境压
• 或选业务低峰期
• 或压测专用域名（同样配置的另一台）

2）压测可能被判为攻击

大量请求可能触发：

• 云平台的 DDoS 防护（IP 被封）
• fail2ban（自己把自己封了）
• CDN 的频率限制

压测时临时关掉 fail2ban 相关规则，或把压测机 IP 加白名单。

3）ab 的并发限制

ab 在高并发时自身可能成为瓶颈（单线程）。并发超过几百建议用 wrk 或多台机器同时压。

4）测试要跑够时间

短时间测试可能测的是缓存效果。建议持续 30 秒以上，且预热后再测。

5）测真实场景

别只压首页。真实用户会访问列表页、详情页、搜索页，压测要覆盖主要接口：

ab -n 1000 -c 50 http://example.com/
ab -n 1000 -c 50 http://example.com/list
ab -n 1000 -c 50 http://example.com/detail/123
ab -n 1000 -c 50 http://example.com/search?q=xxx

十一、一份简单的性能测试报告模板

测试时间：2026-10-13
测试工具：ab 2.3
被测环境：2核4G，Nginx 1.24 + PHP 8.2 + MySQL 8.0

【静态页面】
并发 100：QPS 3200，平均响应 31ms，P99 85ms，失败 0

【首页（动态）】
并发 50：QPS 120，平均响应 415ms，P99 1100ms，失败 0
并发 100：QPS 135，平均响应 740ms，P99 2100ms，失败 3
并发 200：QPS 130，平均响应 1530ms，P99 4200ms，失败 47

【瓶颈分析】
并发 100 以上时，PHP-FPM max_children 打满（listen queue > 0），
MySQL 慢查询日志显示文章列表查询未走索引。

【结论】
当前配置建议承载并发 50 以下；
优化索引 + 调大 max_children 后预计可到 150 并发；
若需更高并发，建议加页面缓存或升级到 4 核 8G。

想知道自己的服务器能扛多少，先压测再优化。财富云计算 的云服务器支持按需升级配置，建议先用低配压测摸清需求，再决定升哪一项，避免盲目买大。内网测试环境可选 NAT 型（无独立公网 IP，价格比带独立 IP 机型省一半以上）。

相关阅读：

• 《服务器资源排查：CPU / 内存 / 磁盘 / 带宽》
• 《PHP-FPM 安装与性能调优》
• 《网站打开慢的排查流程》

延伸阅读

1. 网站环境怎么选：LNMP 手动 / 宝塔面板 / Docker / 云开发
2. 问卷表单系统搭建：SurveyKing / Formbricks，数据自己收
3. 图床搭建：Lsky Pro / Lychee，自托管图片托管方案
4. 邮件列表搭建：listmonk 自托管 Newsletter，把读者握在自己手里
5. 文档站点搭建：MkDocs / VuePress / Docsify，产品文档与技术手册方案
6. RSS 阅读器搭建：FreshRSS 自托管，把信息流拿回自己手里
7. 短链接服务搭建：Shlink 自托管，链接数据自己掌握
8. 网站状态监控页搭建：Uptime Kuma，服务器挂了第一时间知道

更多阅读

1. 上一篇：网站迁移完整流程：换服务器不丢数据、不掉 SEO
2. 下一篇：服务器安全基线检查清单：上线前必做的 30 项