"能扛多少并发"不该是猜的。一次半小时的压测，能提前暴露 CPU 瓶颈、内存泄漏、连接数上限——也能让你在促销/活动前从容扩容。这篇讲工具、方法和容量规划公式。性能分析工具见Linux 性能分析三板斧。

一、先搞懂四个指标

压测前必须认识的术语，不然后面的数字都是天书：

经验基准：网页接口 RT < 200ms 用户无感；P99 > 1s 就开始有投诉。游戏服看 tick 和帧同步稳定性，是另一套标准（见第五节）。

二、工具选型：从轻到重

个人和小团队，wrk 一把梭足够：单核几万 QPS，支持自定义请求头、Body、Lua 脚本。

# 安装（Linux）
apt install wrk        # Debian/Ubuntu
# 或下载编译版，支持 Lua 脚本的完整版

# 基础用法：12 线程 400 连接，压 30 秒
wrk -t12 -c400 -d30s https://yourdomain.com/

# 带 POST 和 Lua 脚本（每请求随机参数）
wrk -t8 -c200 -d60s -s post.lua https://yourdomain.com/api/order

-- post.lua：随机金额下单，模拟真实写操作
wrk.method = "POST"
wrk.headers["Content-Type"] = "application/json"
wrk.body = string.format('{"item":"A10086","qty":%d}', math.random(1, 5))

三、实战：一次完整的压测流程

第 1 步：明确目标

问自己：这次压测要回答什么问题？

• "现在配置能扛多少 QPS？"（基准测试）
• "明天活动预估 500 并发，扛得住吗？"（容量验证）
• "加了 Redis 缓存快了多少？"（优化验证）

没有目标的压测是瞎打。

第 2 步：压测环境

• 别压生产（除非你能接受真实用户受影响）——用一台同配置的机器，或生产低峰期 + 限流保护
• 测试数据要接近真实量级：空数据库的压测结果没有意义
• 监控全程开着（见下）

第 3 步：阶梯加压，别一步到位

# 逐级加压：100 → 300 → 500 → 800 并发，每级 2 分钟
for c in 100 300 500 800; do
  echo "=== 并发 $c ==="
  wrk -t8 -c$c -d2m --latency https://yourdomain.com/
done

第 4 步：看结果，定位瓶颈

# 压测同时，另一个终端盯着系统
top          # CPU
free -h      # 内存
iostat -xz 1 # 磁盘 IO
ss -s        # 连接数
vnstat -l    # 带宽

读报告的姿势：

Running 2m test @ https://yourdomain.com/
  8 threads and 400 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    145.32ms  210.11ms   1.99s    78.35%
    Req/Sec    352.18     89.42     1.2k     71.20%
  336512 requests in 2.00m, 48.32MB read
Requests/sec:   2804.26

• Latency Avg 145ms：平均响应，还行
• Max 1.99s：长尾已经出现，P99 会更差
• Req/Sec 2804：这台配置的实测 QPS 上限
• 结合系统监控：QPS 上不去时，看是 CPU 100%（应用瓶颈）、IO 100%（数据库/磁盘）、还是带宽打满

先崩的组件决定优化方向：

第 5 步：得出容量结论

把阶梯数据整理成一张表，就是你的容量基线：

这张表就是扩容决策的依据：当前日均并发 150，预估活动峰值 400——甜点区到拐点之间，要么提前扩容，要么加缓存把拐点推后。

四、容量规划：三个实用公式

1. 80% 水位原则

任何资源的日常水位不超过 70–80%，留给突发和余量。CPU 长期 95% 的服务器，一次小高峰就雪崩。

2. 峰值系数法

所需容量 = 日均峰值 × 峰值系数 × 增长余量

• 普通业务：峰值系数 1.5（晚高峰是日均的 1.5 倍）
• 游戏服：系数 2–3（周末晚是全周高峰）
• 电商/活动：系数 3–5（大促当天）

游戏服按人数估配置的公式见游戏配置与开服教程总索引。

3. 压测外推法

单机能扛 QPS_1，目标 QPS_2：

需要机器数 ≈ QPS_2 / (QPS_1 × 0.7)     # 0.7 = 安全系数，别跑满

水平扩展前记得无状态化（session 外置），否则加机器不生效，见高可用架构入门。

五、游戏服压测：另一套逻辑

Web 压测看 QPS，游戏服看的是稳定性和 tick：

1. 真实玩家模拟：拉上朋友（或小号）同时在线跑图、打架、交易——没有工具能完全模拟真实游戏行为，人肉压测最靠谱
2. 看 tick 率/帧同步：MC 看 TPS（每秒 tick，掉到 20 以下就是卡）、FPS 游戏看 tickrate 稳定性
3. 长跑观察：连续 24 小时在线，看内存是否缓涨（泄漏）、存档是否正常
4. 配置对照：压完对照配置速查表，人数超了就该升配——游戏服热升级比宕机体面得多

卡顿的在线排查见游戏服卡顿排查。

六、把压测纳入日常

一次性压测会过期（代码在变、数据在涨），健康的做法：

• 重大变更前压一次：新功能上线、大促前、换配置后
• 监控持续做：压测发现的水位线，变成监控告警线（Prometheus）——日常水位触线比压测更早预警
• CI 里跑冒烟压测：每次发布跑 5 分钟轻量压测，性能劣化当天发现，集成方式见CI/CD 指南
• 结果归档：每次压测报告存档，形成性能基线——退步看得见

结语

容量规划的本质是用数据代替猜：一次阶梯压测，一张容量基线表，扩容决策从拍脑袋变成查表。记住两个数——资源的 80% 水位线，和你业务的峰值系数——大部分"突然崩了"都能提前避免。

需要跑压测和生产的服务器，可以看看财富云计算：NAT 型云服务器内存档位全、支持热升级不换机（压测发现不够当场加内存）、SSD 系统盘，价格比独立 IP 机型省一半以上——自用服务、内部系统这类"吃配置不吃公网 IP"的场景，NAT 型刚好对症。

延伸阅读

1. Homepage 个人仪表盘：把散落各处的服务收进一个首页
2. SSL 证书完全指南：免费证书、自动续期与不过期监控
3. 数据备份体系完全手册：从随手拷到 3-2-1，让数据永远丢不了
4. AdGuard Home 内网 DNS：全家去广告、防劫持、内网解析一站解决
5. Hugo 静态博客搭建：秒开的博客，部署只要一个目录
6. 安全应急响应完全手册：服务器被入侵后，按这个流程走
7. 游戏服运营完全手册：从开服到停服，把一台服务器运营成百年老店
8. Loki 日志体系搭建：轻量级日志聚合，Grafana 里查遍所有服务器

更多阅读

1. 上一篇：AdGuard Home 内网 DNS：全家去广告、防劫持、内网解析一站解决
2. 下一篇：数据备份体系完全手册：从随手拷到 3-2-1，让数据永远丢不了