Q62: 如何进行压力测试？
核心结论
压力测试不是“把并发调大跑一次”，而是用可重复的负载模型逼出系统真实瓶颈。
真正有效的压测必须同时回答：
- 压的是什么场景
- 负载模型是否接近真实玩家行为
- 达到极限时系统会怎样退化
- 问题是否可复现、可对比
如果只盯一个“最高在线数”，压测结果通常没有太大决策价值。
一、先区分几种测试目标
常见至少包括：
- 负载测试：验证目标规模是否能稳定运行
- 压力测试：主动冲到系统极限
- 耐久测试：看长时间运行是否泄漏和劣化
- 峰值测试：模拟突发登录、突发广播、活动开启
不同目标的负载模型和验收标准都不同。
二、压测最重要的是负载模型
在线游戏不能只做“空连接压测”。
更有价值的通常是：
- 登录洪峰
- 大量移动同步
- 同屏战斗
- 副本创建和回收
- 邮件、交易、排行等后台链路
因为真正的瓶颈常常不在连接数，而在行为分布。
三、压测要尽量贴近真实玩法节奏
例如：
- 不是所有玩家都每帧发消息
- 不是所有场景都满屏 AOI
- PvE、PvP、主城、活动服的负载完全不同
如果压测脚本过于理想化，最终结论很可能误导优化方向。
四、压测不只是看“能不能扛住”
还要看系统是怎么坏的。
更关键的问题通常包括：
- 先爆 CPU 还是先爆内存
- 是延迟抖动还是直接崩溃
- 是否出现队列堆积
- 是否出现连锁超时
这些决定了后续架构改造方向。
五、压测必须和观测一起做
没有观测的压测价值很低。
至少应该同步采集：
- CPU 和内存
- 线程和锁
- 网络吞吐
- 队列长度
- 关键接口耗时分位数
- 错误率
否则只能看到“挂了”，看不到“为什么挂”。
六、基线和回归很重要
压测不只是为了找上限，也应该用于：
- 建立版本基线
- 对比优化前后收益
- 发现性能回退
没有稳定基线，团队会不断陷入“感觉这版更慢了”的争论。
七、工程上更稳妥的压测流程
常见做法是：
- 明确目标场景和指标
- 构建接近真实的负载模型
- 从低负载逐步加压
- 记录瓶颈点和退化路径
- 优化后回归对比
这样压测结果才真正能指导工程决策。
八、常见误区
1. 连接数就是承载力
不对。真实承载力取决于连接背后的行为模型。
2. 跑一次高峰压测就算通过
不够。长期运行、突发峰值和极限退化都是不同问题。
3. 压测脚本越简单越稳定
简单固然容易复现，但如果脱离真实业务，结论会失真。
参考资料
- 各类在线游戏压测、回放和容量评估实践资料