《游戏服务端编程实践》附录 B：性能调优 Checklist

一、Checklist 不是许愿单

性能调优最常见的失败，不是“没有检查项”，而是“检查项都打了勾，事故还是发生了”。原因通常有三个：没有基线、只测平均值、只测正常路径。Checklist 的价值在于强迫团队在同一个问题上使用同一套证据，而不是提供一张可以交差的表格。

使用这份清单前，先约定四条规则：

1. 先有基线：没有调优前的数据，就无法判断变化是优化还是波动。
2. 一次只改一个变量：同时改连接池、GC 参数和序列化格式，结果无法归因。
3. 记录环境：机器规格、内核参数、运行时版本、数据集大小、并发模型都要写进报告。
4. 定义回滚：每个改动都要能在十分钟内撤回，并知道撤回后看哪个指标。

文中的阈值都标注为“经验值”，它们来自常见项目的量级，不是在本项目环境测得，也不能直接照搬。正确用法是把它当作起点，再用自己的基线校准。

指标口径也要提前统一。吞吐量是每秒处理多少请求还是每秒完成多少业务动作？延迟是从客户端发出算起，还是从服务端收到算起？错误率是否包含客户端主动取消和网络中断？同一个数字在不同口径下可能相差数倍。建议在报告首页写清楚四个定义：请求边界、成功判定、统计窗口、百分位算法。没有这四项，前后对比就没有意义。

还要区分“资源指标”和“体验指标”。CPU、内存、连接数是资源指标，能解释瓶颈；登录耗时、消息延迟、战斗结算时间是体验指标，才直接对玩家负责。调优时先用体验指标定位问题，再用资源指标找原因，顺序反了就容易陷入“CPU 降了但玩家更卡”的怪圈。

二、连接与网关

连接层是游戏服务端最先承压的地方。这里的错误往往不是“慢”，而是“直接不可用”：文件描述符耗尽、accept 队列溢出、心跳把连接全部踢掉。

连接数不能拍脑袋估算。一个玩家可能同时有登录连接、战斗连接和推送连接，重连期间还会短暂出现新旧连接并存；如果按“在线人数 = 连接数”做容量规划，峰值会明显偏低。规划时应分别估算稳定连接、峰值连接和故障恢复连接，并给文件描述符、内存与端口留出余量。

网关层要特别关注“重连风暴”。服务端重启或网络抖动后，大量客户端会在同一秒重连；如果登录、拉取数据、进入场景都是同步重操作，网关会在恢复瞬间再次被打满。常见缓解手段是随机退避、分批放行、缓存热点数据，以及把非关键初始化延后。

三、协议与序列化

协议层的性能问题通常被“网络慢”掩盖。实际原因可能是序列化占用过多 CPU、消息体过大、或者每次编解码都产生大量临时对象。

测序列化时要把编码和解码分开统计。很多格式编码快、解码慢，或者在小消息上表现很好、在大消息上突然退化。还要用真实的消息分布测试，而不是只测一条最典型的请求；战斗广播、排行榜拉取、聊天消息的体积差异很大，平均值会掩盖长尾。

序列化选型不应只看编码速度。解码速度、兼容策略、跨语言支持、调试可读性和工具链同样重要。已有章节 Protobuf 与 FlatBuffers 讨论过不同格式的取舍，这里再强调一点：如果协议没有版本策略，任何格式都救不了升级事故。

四、并发与调度

并发层的核心不是“线程越多越好”，而是“排队时间可控”。游戏服务端常见模型包括每连接协程、固定 worker 池、分片事件循环和 Actor。不同模型的检查项不同，但都要回答同一个问题：请求在队列里等了多久。

并发模型没有绝对优劣。每连接协程写起来简单，但连接数极高时调度与内存成本要核算；固定 worker 池容易控制资源，但慢任务会阻塞同池请求；分片事件循环减少锁竞争，却带来分片倾斜和跨片通信问题。选择模型后，必须把“队列等待时间”作为一等指标，而不是只看 CPU。

五、内存与 GC

内存问题的危险在于它通常不是立刻崩溃，而是慢慢变差：分配率上升、GC 更频繁、尾延迟变高，最后在高峰时刻 OOM。检查时要区分“常驻内存”“临时分配”和“泄漏趋势”。

出现内存异常时，先保留现场再重启。堆转储、分配剖面、goroutine/线程快照和最近一次 GC 日志，往往比“重启后恢复了”更有价值。如果容器会在 OOM 时直接杀进程，要提前配置转储路径和持久化卷，否则事故现场会随进程一起消失。

GC 调优不是“把参数调到最优”，而是先减少不必要的分配。一个每帧创建大量临时对象的战斗循环，靠调 GC 参数只能缓解症状。反过来，如果分配已经很低，GC 参数才有意义。还要注意运行时是否感知容器内存限制；很多“神秘 OOM”其实是堆上限按宿主机内存计算，远超容器配额。

六、数据库与缓存

数据库层的检查项要围绕“请求量、延迟、连接、锁、复制”展开。缓存则要围绕“命中率、热点、失效、一致性”。两者不能混为一谈：缓存命中率高不代表数据库没问题，可能只是把问题延后了。

数据库性能的第一原则是“先看执行计划和数据量”。同一条 SQL 在测试库上很快，不代表在生产数据量下也快。第二原则是“连接池不是越大越好”，连接数超过数据库承载后，等待和上下文切换会让整体更慢。缓存则必须回答“失效后怎么办”，否则命中率越高，故障时的穿透越猛。

七、消息与队列

消息层的检查项围绕“积压、重试、顺序、幂等、死信”。游戏服务端常用消息处理跨服、异步任务、日志与补偿，一旦积压，表现可能是玩家操作延迟而不是消息系统报错。

消费能力不足时，第一反应通常是加消费者，但分区数决定了并行度的上限。如果分区数少于消费者数，多出来的实例只能空闲；如果分区倾斜严重，加机器也救不了热分区。扩容前先看每个分区的积压与吞吐，确认瓶颈在消费者、分区还是下游存储。

消息系统最常见的错误，是把“至少一次”当成“恰好一次”。只要存在重试，就必须有幂等键；只要存在多分区，就必须明确哪些操作需要保序。积压告警不能只看队列长度，还要看增长斜率：一个稳定在十万条的队列可能是正常的，一个五分钟内从零涨到一万条的队列才是事故前兆。

八、日志与监控

日志与监控不是“上线后再补”的附属品，而是性能调优的测量工具。检查重点是：指标是否能回答问题、日志是否可承受、告警是否可行动。

日志与指标的保留周期要和排障需求匹配。只保留三天，可能撑不到一次跨周复盘；保留一年又不分层，成本会失控。常见做法是热数据保留数天供实时查询，温数据保留数周供复盘，冷数据归档到对象存储。无论哪一层，都要保证按键和时间可检索，否则“有数据”等于“没有数据”。

监控的第一目标是“缩短定位时间”，不是“收集尽可能多的数据”。一个只有 CPU 和内存的仪表盘，无法回答“是网关慢还是逻辑慢”；一个标签爆炸的指标体系，可能在故障时先把自己拖垮。日志同理：结构化字段比长文本更有用，采样与脱敏必须在写入前完成。

九、发布与容量

发布阶段的性能问题往往来自“变化”：新版本更耗内存、连接没有优雅迁移、缓存冷启动、自动扩缩容反应太慢。检查项要覆盖发布前、发布中和发布后。

压测的加压方式也要写清楚：是瞬间打到目标并发，还是分阶段爬坡。瞬间加压适合验证极限，分阶段爬坡更接近真实开服；两者得到的结果不能混用。至少要记录每个阶段的连接数、消息速率、延迟分位和错误率，才能判断系统是在哪个拐点开始退化。

容量评估不能只看应用层。应用扩容三倍，数据库连接数和缓存带宽也会随之上升；如果下游没有同步准备，扩容只会把瓶颈前移。发布时还要考虑“连接是有状态的”：滚动重启如果直接杀进程，玩家会同时重连，恢复瞬间的负载可能高于平时。

十、压测前后对照清单

压测报告至少要有“调优前”和“调优后”两列，并且使用同一套场景、同一份数据、同一批机器。报告开头要写清楚“本次要回答的问题”，例如“连接数从一万提升到五万时，p99 是否仍低于 200ms”。没有问题陈述，数据再多也无法形成结论。

下面是一个可以直接复用的对照表模板。

百分位的计算方式要在两张表里保持一致。常见错误是调优前用固定时间窗口统计，调优后改成按请求统计，结果 p99 看起来大幅改善，实际只是口径变了。压测工具如果存在 coordinated omission，即客户端在等待响应时没有继续按计划发请求，测出的延迟会偏乐观；长连接游戏尤其容易踩这个坑。报告里应说明是否使用开环加压、是否记录未完成请求。

对照表要保留原始数据与采集命令，不能只留下结论。否则下一次调优时，团队无法判断“当时的 p99 是在什么连接数、什么消息比例下测出来的”。

十一、上线前 30 分钟检查清单

上线前的检查目标不是“再优化一点”，而是“确认可观测、可回滚、可恢复”。下面这张表按时间倒排，负责人和证据必须填写。

如果任何一项没有证据，就不应该开始发布。上线前 30 分钟不是用来“再改一版”的，而是用来确认“出问题时知道怎么办”。

可以用一份 YAML 把性能门禁固定下来，接入发布流水线或人工评审。阈值只是模板，必须按项目基线调整。

performance_gate:
  baseline_required: true
  environment: staging
  metrics:
    connect_success_rate:
      target: ">= 0.999"
    gateway_p99_latency_ms:
      target: "<= 200"
    business_error_rate:
      target: "<= 0.005"
    cpu_peak_ratio:
      target: "<= 0.70"
    heap_peak_ratio:
      target: "<= 0.70"
    queue_growth:
      target: "no sustained growth"
  failure_injection:
    required:
      - kill_instance
      - disconnect_network
      - downstream_timeout
  rollback:
    max_minutes: 10
    verified: true

门禁的意义是让“是否达标”可复核，而不是让流水线替团队承担判断。指标口径、采样窗口和失败注入场景都要写在报告里，否则同一份 YAML 可以被不同的人解释成不同结论。

十二、失败场景：全绿的 Checklist 为什么没救回事故

某项目上线前完成了全部检查：连接成功率、CPU、内存、数据库延迟都在阈值内，压测报告全绿。上线当晚，一次机房网络抖动导致大量玩家掉线，随后客户端同时重连，网关在几分钟内不可用。事后复盘发现，Checklist 里的每一项都没错，但测的都是“稳态”。

事故的根因不是某个指标超标，而是“测试场景与真实故障不匹配”。稳态数据只能证明系统在正常输入下可用，不能证明它在抖动、重连、依赖变慢时仍然可用。性能 Checklist 必须包含失败路径，否则它只是一份上线安慰剂。

小结

性能调优的八层检查可以概括为一句话：先建立基线，再逐层找瓶颈，最后用故障场景验证。连接层看容量与重连，协议层看体积与分配，并发层看排队，内存层看趋势，数据库层看执行计划与连接池，消息层看积压与幂等，监控层看可行动性，发布层看余量与回滚。所有阈值都是经验起点，必须用项目自己的数据校准。Checklist 的终点不是打勾，而是让团队在事故发生时能快速回答“哪里慢、为什么慢、怎么恢复”。

常见错误与边界

• 把 Checklist 当形式：只打勾不留证据，评审时无法判断结论是否成立。
• 只检查不修复：发现慢查询、队列增长却不排期处理，清单反而掩盖风险。
• 阈值照搬别的项目：别人的 p99 目标、连接数和机器规格与你不一定相同。
• 只看平均值：平均值正常不代表尾延迟正常，游戏体验由 p99 甚至 p999 决定。
• 只测稳态：没有断网、重启、依赖超时和重连风暴的压测，不能证明故障可恢复。
• 一次改多个变量：无法归因，也无法判断哪个改动真正有效。
• 监控指标越多越好：高基数标签会拖垮存储，告警过多会导致疲劳。
• 上线前临时调参：没有基线、没有回滚的改动，往往把小问题变成大事故。