负载测试
负载测试通过模拟并发玩家访问您的基础设施，在真实玩家进入之前找出系统崩溃的瓶颈。它能回答任何代码审查都无法解答的问题：您的架构在多大的并发量下会崩溃、分配何时开始排队，以及什么会最先失效。其目的在于刻意寻找系统的上限。
又称
负载测试
，
什么是负载测试？为什么对于游戏而言“尖峰测试”是最难的测试？
负载测试是一个测试系列，每个测试都解答一个不同的问题。k6 文档列出了六种（Grafana k6）：
测试 | 检查内容 | 在游戏中呈现的形式 |
|---|---|---|
冒烟测试 (Smoke) | 脚本和设置是否正常工作 | 从头到尾的几场比赛 |
平均负载 (Average load) | 典型流量下的行为表现 | 正常的每日高峰 |
压力测试 (Stress) | 高于正常流量时的行为表现 | 预期高峰的两倍 |
尖峰测试 (Spike) | 突然的流量激增 | 活动开始或发布首小时 |
浸泡测试 (Soak) | 长期运行的稳定性 | 数小时或数天，以捕获泄漏 |
断点测试 (Breakpoint) | 系统在何处停止工作 | 不断增加比赛，直到出现故障 |
本页重点讨论尖峰测试，这可能是多人游戏中最难的一项。玩家的涌入意味着比赛的激增，而每场比赛都需要专属的服务器，这些服务器需要按需启动并维持运行数分钟或数小时。以 2,000 名并发玩家、每局 4 人为例：这意味着有 500 台服务器同时运行。如果每分钟开始 20 场新比赛，且每场持续约 25 分钟，那么在高峰期会有 500 台服务器在线。尖峰会提高到达率，因此匹配系统、服务器请求和通知都会在同一时刻感受到压力。
尖峰也不是瞬间发生的。玩家会成波到来，在一秒钟内创建一千台服务器，多半只会证明请求限制会拒绝你。因此，请按照实际流量的行为方式来塑造激增：
陡峭爬升，而非瞬间完成。 缓慢开始，分步攀升，然后保持。
增加随机性。 不要精确到整秒边界创建服务器，因为真实比赛的形成存在自然偏差。
改变比赛时长。 有些比赛很快结束，有些则运行较长，因此释放容量是不均匀的。
分散玩家分布。 玩家来自多个地区，这会影响服务器的部署位置。
保持足够长的时间。 短暂的爆发会掩盖运行数小时后才会出现的问题。
其他五种测试也遵循相同的形态：只需改变爬升的高度，或保持的时长。
游戏负载测试应该涵盖哪些内容？
不仅仅是游戏服务器。一场比赛会经过一系列环节，而最薄弱的环节决定了整体上限：
阶段 | 可能出现故障的地方 | 需要监控的指标 |
|---|---|---|
匹配系统 (Matchmaker) | 玩家票据堆积，组队速度缓慢 | 从玩家购票到成功匹配的时间 |
服务器分配 (Allocation) | 服务器请求被延迟或拒绝 | 从“找到匹配”到“服务器就绪”的时间、错误率 |
通知发送 | 后端遗漏了“服务器已就绪”的消息 | 遗漏或重复的通知 |
后端与数据库 | 查询缓慢、连接耗尽 | 查询时间、错误数 |
游戏服务器 | 内存泄漏、负载下 Tick Rate 出现漂移 | Tick 时间、数小时内的内存变化 |
清理回收 | 比赛结束后服务器仍在继续运行 | 残留的服务器数量 |
内存泄漏、慢数据库查询和低效的网络代码是常见的问题，而如果测试仅要求服务器启动，这些问题都不会暴露出来。
测试你实际会运行的整个链条。如果测试绕过匹配系统，只是循环调用分配 API，那么它测试的只是 API，而不是你的实际启动流程。匹配系统涵盖了真实玩家如何排队，而可扩展性则涵盖了如何规划目标规模。
游戏测试应该使用哪种负载测试工具？
三个开源工具涵盖了大多数团队，其选择主要取决于您的团队喜欢如何编写测试：
Apache JMeter 具有可视化界面和内置报告，因此适合喜欢无需代码即可构建场景的团队。它支持 HTTP 和 TCP 等，并可以分布式运行。
k6 使用 JavaScript 编写测试，因此它们存在于版本控制中并在 CI 管道中运行。
Locust 使用 Python 编写测试，并可以分布式运行在多台机器上。
这三个工具都擅长一项工作：驱动技术栈的 HTTP 端，例如撮合服务票据、服务器请求和 webhook 处理程序。但它们都不运行您的游戏。要测试连接本身，您需要客户端机器人，而这才是真正的决定所在。Edgegap 的指南将其视为可选但有价值：连接到每个就绪服务器的机器人可以显示报告“就绪”的服务器是否接受玩家，而更便宜的备用方案是测试到每个服务器地址和端口的原始网络连接（文章 246）。机器人需要花费工程时间，并且连接性检查无法告诉您比赛是否正常进行。
如何运行测试并在测试后进行清理？
从与您的发布相匹配的配置文件开始，然后对其进行调整。Edgegap 的指南提供了三种配置，每种配置都包含一个爬坡阶段，随后是一个保持阶段（文章《如何针对任何多玩家游戏运行压力测试》）：
配置文件 | 同时在线玩家 | 每局玩家数 | 每分钟新对局数 | 爬坡，然后保持 |
|---|---|---|---|---|
独立游戏发布 | 200 | 2 | 5 | 10 分钟，然后保持 60 分钟 |
中型游戏 | 2,000 | 4 | 20 | 20 分钟，然后保持 90 分钟 |
测试周末 | 10,000 | 6 | 50 | 30 分钟，然后保持 2 到 4 小时 |
目标本身来自预测，这在可伸缩性中有所涵盖。然后分五个阶段运行，以下详细信息以 Edgegap 的 API 作为工作示例。
准备测试客户端。这是您匹配后端的简化版本，用于组建对局、请求服务器、处理通知并记录每个事件。
服务器创建爬坡。遵循上面的曲线，并留意频率限制错误。
跟踪就绪状态。测量从请求到“就绪”的时间，并调查每个未能达到就绪状态的服务器。
连接玩家。如果有机器人就使用机器人，如果没有，则进行原始连接性检查。
清理和验证。结束对局，然后扫描遗留的服务器。
频率限制。截至 2026 年 10 月 13 日，Edgegap 的API 文档列出，每个组织每秒部署请求限制为 40 次，状态和上下文端点限制为 20 次。超过该限制，请求将收到 HTTP 429 响应。如指南所建议，采用指数退避并遵守返回的 Retry-After 标头（如果存在），并在一段时间内分摊请求，而不是发送突发请求。
通知。当服务器就绪、启动失败或终止时，会触发 Webhook。它们不会重试，因此您的处理程序必须容忍丢失的消息和重复的消息，并且您的后端应该保存每个服务器状态的专属记录。将状态端点保留为备用手段，因为轮询数百个服务器会迅速耗尽频率限制。
清理。当您的后端删除服务器、游戏服务器自身停止或达到最大持续时间时，服务器就会结束。标记每个测试服务器，以便您稍后可以找到它，并将残留的服务器视为清理工作中的一个 bug，因为它会增加成本并影响下一次运行。
来自我们的赞助商（其实就是我们自己！）的寄语
大多数工作室在游戏上线并面对玩家时，才发现自己的扩容瓶颈。而 Edgegap 在针对真实游戏服务器容器的一小时基准测试中，达到了 1400 万并发会话，因此你需要考虑的限制在于你的游戏本身，而非你的托管服务商。
Edgegap 的观点（仅代表个人意见，姑且听之即可！）
在发布前运行负载测试，覆盖整个链条，并提前通知您的服务商
压力测试是一场排练，因此只有在足够早的时候运行，才能发挥其价值并做出调整。在发布前几周进行试运行，可以留出时间修复发现的问题。而在发布前一天晚上运行，只会让人感到焦虑。
覆盖整个链条，因为天花板通常是游戏构建之外最薄弱的环节，比如通知处理程序、数据库或匹配器设置。
并先通知您的服务商。对于大型测试，Edgegap 会要求提前通知，以便预先扩展容量并在测试窗口期内提高速率限制。否则，您最终可能会测量的是服务商的冷启动，而不是您自己的系统。我们指南的阈值是持续每秒 20 次以上的部署，或峰值运行约两小时（文章 246）。有关目标规模的讨论在可扩展性中有所涵盖。
这也是有成本的：一个现实的测试需要工程时间、暂存环境以及提前通知的准备时间。一个只有几百名玩家的小型游戏可能不需要这一切。但对于停机代价高昂的游戏发布来说，我们认为跳过这一步代价更高。在 Edgegap 2023 年的基准测试中，持续 60 分钟每秒 40 次的部署在当时分布于 550 多个地点的节点上达到了 1400 万的最高同时在线人数（CCU）（基准测试）。
，
