全栈攻城狮

Appearance

压力测试体系 ​

概述 ​

压测是性能工作的"验证器"：上线前的容量评估、优化后的效果对比，都靠压测说话。游戏压测与普通 Web 压测不同：有状态（真实协议交互）、长连接（千人同服）、实时性（RT 敏感）。本文建立完整的压测体系：压测客户端、QPS/RT 评估、千人在线测试、瓶颈定位。

一、压测客户端编写 ​

1.1 工具选型 ​

压测工具：
  JMeter：通用 HTTP/TCP 压测，脚本化
  Netty 自研压测客户端：模拟游戏协议（推荐）
  Gatling/自定义：高并发模拟

游戏场景选择：
  协议压测 → 自研 Netty 客户端（精确模拟）
  网关 HTTP 接口 → JMeter
  登录洪峰 → 自研多账号模拟
// 自研压测客户端骨架（Netty 模拟大量客户端）
public class LoadClient {
    public static void main(String[] args) {
        int users = 5000;   // 模拟 5000 玩家
        for (int i = 0; i < users; i++) {
            connectAndPlay(i);   // 每个客户端登录 + 操作
        }
    }
}

1.2 场景设计 ​

压测场景：
  登录场景：并发登录（注册/Token）
  对局场景：匹配 + 对战操作（核心）
  混合场景：登录 + 对局 + 聊天（接近真实）
  尖峰场景：开服瞬间（全部同时登录）

压测数据：
  真实账号池（预注册）
  随机操作（符合玩家行为分布）
  多机房/多节点分布

二、QPS/RT 指标评估 ​

2.1 核心指标 ​

指标定义：
  QPS：每秒处理请求数
  RT（响应时间）：p50/p95/p99
  成功率：失败请求占比
  吞吐：字节/秒（带宽）

游戏关注：
  p95/p99（多数玩家的体验，不能只看 p50）
  长尾延迟（对局卡顿感知）
  成功率（对局中断/失败）

压测结果评估示例：
  QPS: 12000      # 达标（目标 10000）
  p50: 5ms        # 中位延迟良好
  p95: 18ms       # 95% 玩家延迟可接受
  p99: 120ms      # 长尾略高（分析瓶颈）
  成功率: 99.98%  # 极少量失败（检查超时）

2.2 容量评估 ​

容量评估方法：
  阶梯加压：1000 → 2000 → 5000 → 10000
  找到性能拐点（RT 急剧上升/QPS 不再增长）
  拐点 = 容量上限 → 留余量

SLA 制定：
  目标 RT（如 p95 < 50ms）
  目标在线（如 1 万同时在线）
  尖峰余量（1.5-3 倍）
拐点判断：
  QPS 不再随并发增长（达到瓶颈）
  RT 指数上升（排队）
  错误率上升（超时/拒绝）
  资源打满（CPU/连接数/内存）

三、千人同服在线测试 ​

3.1 长连接测试 ​

千人同服特点：
  长连接（WebSocket/TCP 保持）
  每连接周期性消息（心跳/操作）
  关注连接稳定性（不超时/不断开）

压测方式：
  建立 N 连接（模拟 N 人在线）
  每连接按节奏发消息
  持续压测（数小时稳定性）
  观察连接数曲线/断线率
// 在线模拟示例（每连接定时操作）
channel.eventLoop().scheduleAtFixedRate(() -> {
    channel.writeAndFlush(randomOperation());
}, 0, 3, TimeUnit.SECONDS);

3.2 稳定性测试 ​

稳定性关注点：
  内存增长（泄漏检测）
  连接数稳定（泄漏/堆积）
  GC 频率（停顿影响对局）
  消息延迟（随时间恶化？）

持续时长：
  短时（30 分钟）：功能与初步容量
  长时（数小时-数天）：泄漏与稳定性
  峰值 + 持续：真实运营场景模拟

四、瓶颈定位与优化 ​

4.1 定位方法 ​

瓶颈定位工具：
  JProfiler/Async Profiler：CPU/内存火焰图
  Arthas：在线诊断（见监控章节）
  JFR：飞行记录（见监控章节）
  监控面板：QPS/RT/资源曲线

常见瓶颈：
  CPU 瓶颈：业务计算/GC/序列化
  线程瓶颈：线程池耗尽/锁竞争
  IO 瓶颈：DB/Redis/网络
  内存瓶颈：GC 频繁/泄漏
定位流程：
  1. 压测复现（固定场景）
  2. 资源曲线看哪项打满（CPU/IO/网络）
  3. profiler 采样定位热点代码
  4. 针对性优化 → 复测对比

4.2 优化对照 ​

优化验证：
  优化前基线（QPS/RT）
  优化后复测（同场景）
  对比提升幅度

常见优化方向：
  代码层：算法/序列化/对象复用
  Netty 层：内存池/线程数（见 Netty 调优）
  JVM 层：GC/堆（见 JVM 调优）
  数据层：SQL/缓存（见 DB 调优）
  架构层：分片/异步（见水平扩展章节）

五、实现要点 ​

压测体系：
  自研协议压测客户端（模拟真实交互）
  场景设计（登录/对局/尖峰）
  指标（QPS/RT p95-p99/成功率）
  阶梯加压找拐点（容量）
  千人长连接稳定性（持续压测）
  瓶颈定位（profiler + 监控）→ 优化复测

常见坑：
  只看 p50（忽视长尾）
  压测数据不真实（固定请求）
  单机压测不代表集群
  优化不对比基线（无说服力）
与其他系统衔接：
  瓶颈修复 → Netty/JVM/DB 调优章节
  监控 → 监控章节
  容量规划 → 水平扩展章节
  上线 → 运维章节