免责声明：请确保在运行负载测试之前联系我们。

本指南将介绍如何进行在线多人游戏的负载测试，特别是 對局配對 和 游戏服务器部署（包括使用哪些工具），该测试是在 Edgegap 平台上使用 Edgegap API 进行的。

本指南适用于任何游戏引擎（例如 Unreal Engine、Unity 等）、任何游戏类型以及所有目标硬件（PC、主机、VR、WebGL、移动端等）。

涵盖的主题（按章节分类）：

1. 前提条件

2. 對局配對流程与部署计划

3. API 速率限制

4. 部署 API

5. 部署生命周期管理

6. 部署状态

7. Webhook

8. 负载测试执行计划

9. 真实流量建模

10. 流量配置文件

11. 流量目标

12. 何时需要 Edgegap 团队的介入

13. 推荐工具

注意：如果您不使用 Edgegap 的對局配對，可以跳过并直接前往第 4 节“部署 API”。

目标受众

本文档适用于后端工程师、DevOps 团队以及准备进行产品发布的游戏工作室。

目标时间表

虽然运行负载测试永远没有最理想的时间，但我们建议在发布前几周进行一次演练，以评估多人游戏架构中的任何薄弱环节。

请参阅我们的多人游戏发布前检查清单，获取发布前的推荐时间表。

什么是多人游戏负载测试，以及它为什么重要

负载测试是一种性能测试，通过模拟大量并发玩家 （“CCU”），来评估多人游戏的底层架构在压力下的表现，包括對局配對和游戏服务器部署。

通过在发布前进行负载测试，可以发现内存泄漏、数据库查询瓶颈、低效的网络代码等问题，并在发布前予以解决。

正如我们过去经常提到的，如果无法做好准备并在发布时进行无缝扩展，可能会因为游戏无法访问（即使您在发布前投入了 AAA 级别的资源来避免这种情况）而让游戏开发者损失数百万美元。

因此，游戏工作室才会使用 Edgegap 游戏服务器编排服务，该服务已被证明能在 60 分钟内无缝扩展至 1400 万并发玩家，并在该期间持续保持每秒 40 次的部署速度，因此在初始阶段之后还会有更多。 

1. 前提条件

• 此步骤的目标：确保您已具备负载测试所需的前提条件。 

• 目的：确保您的测试环境与您的生产配置完全一致。

Edgegap 提供 HTTP API 来管理游戏服务器部署。提醒一下，部署是在 Edgegap 的边缘网络上运行的游戏的容器化实例。

在进行负载测试之前，请确保您拥有：

• 已配置计费信息的 Edgegap 账户

• 一个 API 令牌

  • 注意：您的 API 令牌将包含在每个请求标头中，如下所示：Authorization: token <your-token>。请妥善保管此令牌，因为它拥有对您 Edgegap 资源的完整访问权限。

• 打包为 Edgegap 应用版本的容器化游戏服务器

• 能够进行 HTTP API 调用 的后端系统

请注意，API 参考文档可在我们的网站上找到：https://docs.edgegap.com/docs/api

2. 了解對局配對与部署计划

• 此步骤的目标：理清您的對局配對系统是如何将玩家行为转化为部署请求的。

• 目的：在游戏部署流程中准确模拟真实玩家的行为。同时估算足够的部署量，以匹配能够反映发布首日情况的性能数据。

在生产多人游戏环境中，您的對局配對流程通常如下所示：

玩家登录 → 對局配對队列 → 找到对局 → 创建部署 → 服务器就绪 → 玩家连接 → 对局进行中 → 删除部署

这里的关键点在于，每场对局都需要恰好一个部署。这种一一对应的关系是您进行容量规划的基础。

计算您的部署需求

让我们来做一下数学计算。如果您的游戏在每个服务器实例上支持 N 个玩家，您就可以精确计算出可能需要多少个部署：

这实际上意味着“所需部署数”是预期的目标部署数量。

估算玩家基数扩展

根据每个总玩家数对应的部署数量，下一步是估算这些部署随时间推移的数量（即“扩展”）。

在这方面，大多数游戏开发者会犯的错误是在几分钟内对整个玩家群进行负载测试，从而高估了扩展到发布目标所需的每秒部署数。

举个例子，世界上最受欢迎的游戏《堡垒之夜》（Fortnite）历史最高同时在线人数达到 1430 万，估计每秒有 100 次部署。然而，《堡垒之夜》在每日高峰期的平均每秒部署数为 30-40 次。因为玩家加入和离开游戏是根据他们的日常生活（睡觉、上班）像波浪一样起伏的。因此，现实情况下，即使游戏在世界范围内同时发布，负载测试也应考虑到在 60 分钟内扩展到其高峰发布同时在线人数的 25-50%，这样才比较符合实际。

例如，公式为：（所需部署数 * 预估高峰百分比）/ 3,600 秒 = 负载测试的目标每秒部署数

3. 遵守 API 速率限制（至关重要）

• 此步骤的目标：了解并遵守服务器部署的速率限制。

• 目的：确保您的负载测试反映了现实世界的约束。避免在测试期间达到速率限制，因为这可能会掩盖真实的性能问题。虽然不太可能，但如果您在生产环境中遇到相同的限制，您的测试必须将其考虑在内。

Edgegap 强制实施整个组织范围的速率限制以确保系统稳定性。这些限制适用于整个组织。

请参考文档，但在撰写本文时，Edgegap 的 API 速率限制如下：

特别是对于對局配對，每个层级都有以下限制：

当您超过这些限制时，API 将返回 HTTP 429 – Too Many Requests（请求过多）。请务必遵守这些限制以避免此错误消息。

合规速率限制的最佳实践

要在限制范围内确保可靠的性能：

• 当您收到 429 响应时，实施指数退避。不要立即重试，因为这会加剧问题。

• 始终遵守 429 响应中的 Retry-After（重试于...之后）标头。它会确切告诉您在重试之前需要等待多长时间。

• 通过将部署请求分配在一段时间内进行，来避免突发的高峰。无论如何，逐渐增加请求更符合实际情况。

• 使用 Webhook 代替轮询来跟踪部署状态。这可以大大减少您的状态端点使用量。

⚠️ 重要提示：如果您计划进行大规模的负载测试（数小时的持续负载或高部署率），请提前与 Edgegap 支持团队协调。他们可以临时提高您的限制并预先扩展容量，以确保获得准确的测试结果。

4. 通过 API 创建部署

• 此步骤的目标：学习如何以编程方式创建具有合适配置和监控的游戏服务器部署。

• 目的：进行 API 调用是部署流程的核心。它能确保您的服务器在适合所有玩家的最佳位置进行部署，并确保正确的 Webhook 通知。

创建部署端点是您启动游戏服务器的主要接口。

创建部署端点

端点：POST https://api.edgegap.com/v2/deployments

速率限制：40 次请求/秒（整个组织范围）

必需的标头：

Authorization: token <your-token>
Content-Type: application/json

请求体示例

以下是一个完整示例，展示了您应该包含的所有关键参数：

{
  "application": "my-game-server",
  "version": "v1.0.0",
  "users": [
    {
      "user_type": "ip_address",
      "user_data": {
        "ip_address": "1.2.3.4"
      }
    }
  ],
  "tags": ["matchmaking", "load-test"],
  "webhook_on_ready": {
    "url": "https://your-backend.com/webhooks/deployment-ready",
    "method": "POST"
  },
  "webhook_on_error": {
    "url": "https://your-backend.com/webhooks/deployment-error",
    "method": "POST"
  }
}

了解关键参数

• 用户数组 (users array)：这是 Edgegap 确定您部署的最佳地理位置的方式。请包含将连接到此对局的玩家的 IP 地址。系统会使用此信息来选择能够将所有参与者延迟降至最低的边缘位置。

• Webhook：强烈建议使用它，而不是进行轮询。Webhook 会在部署就绪或遇到错误时立即为您提供通知，让您能够立即将玩家移入对局，而无需进行不断的进行状态检查。

• 标签 (tags)：使用标签来组织和过滤您的部署。在负载测试期间，标签可帮助您识别哪些部署属于您的测试流量，哪些属于生产流量。

5. 管理部署生命周期

• 此步骤的目标：实施正确的部署清理，以避免浪费资源并确保准确的负载测试指标。

• 目的：没有正确终止的孤立部署会增加您的成本、消耗容量，并使您的负载测试结果变得毫无意义，因为您需要了解系统如何处理完整的 创建-运行-删除 循环。

负载测试中一个常见的错误是只关注部署的创建，而忽略了清理。在真实的生产环境中，对局结束时会终止服务器，以避免过度开销资源。您的负载测试必须模拟这个完整的生命周期（并为您节省负载测试本身的费用）。

从您的后端删除部署

当对局结束时，您的對局配對后端应该立即删除该部署。

端点

DELETE https://api.edgegap.com/v2/deployments/{request_id}

标头

Authorization: token <your-token>

当您创建部署时，会返回 request_id。将此 ID 存储在您的對局配對系统中，以便在对局结束时进行引用。

替代方案：自行终止（即让游戏服务器来决定）

还有一种更具弹性的替代方法：每个部署都包含一个唯一的删除 URL 和令牌，允许游戏服务器自己在适当的时候关闭。当您的游戏逻辑最清楚对局何时真正结束时，这特别有用。

例如，您的游戏服务器可能会等到所有玩家断开连接、上传对局后统计数据并保存所有录像后，再触发其自身的终止。这种方法可以确保在清理过程中不会丢失任何内容。

在 Edgegap 部署生命周期文档中，深入了解有关自行终止的更多信息。

提醒：未能终止服务器的成本

未能正确删除部署会导致：

• 由于需要为空闲服务器付费，因此会导致成本急剧上升

• 由于看起来您需要的容量比实际需要的要多，这会使您的负载测试结果产生偏差

• 由于您的控制面板中充斥着僵尸部署，从而产生运维问题

在负载测试期间，使用 Edgegap 分析实施监控，以检测任何未被正确清理的部署。

-> 这些孤立的部署是一个警示，表明您的生命周期管理在发布前必须进行调整。

6. 跟踪部署状态

• 此步骤的目标：了解如何监控部署就绪状态，而不用因为状态检查导致 API 过载。

• 目的：确切地知道部署何时准备好接受玩家，对于對局配對流程至关重要。但是，频繁的轮询可能会触发速率限制，并且不能反映生产环境的最佳实践。

创建部署后，您需要知道它何时准备好让玩家进行连接。有两种方法：轮询状态端点或使用 Webhook。其中一种方法明显优于另一种。

Webhook：正确的方法

与其每秒都询问“准备好了吗？”，不如让 Edgegap 在发生变化时立即通知您。这就是 Webhook 的作用，它们是生产系统推荐的方法（参见第 7 步）。

当您在创建部署请求中包含 Webhook URL（如第 4 节所示）时，Edgegap 将在部署就绪或遇到错误的瞬间向您的后端发送 HTTP POST。然后，您的系统可以立即将玩家分配到该对局服务器，而无需任何轮询延迟。

最佳实践：将 Webhook 作为您的主要通知机制。将状态端点留给您需要手动检查部署状态的特殊情况——可能是调试期间或处理罕见的边缘情况。

状态端点（谨慎使用）

GET https://api.edgegap.com/v1/status/{request_id}

速率限制：10 次请求/秒

此端点返回部署的当前状态：

• Status.DEPLOYING – 服务器正在启动

• Status.READY – 服务器已准备好进行玩家连接

• Status.ERROR – 部署期间发生错误

虽然此端点可以工作，但针对数百个部署反复轮询很快就会出现问题。您会耗尽速率限制，并给 API 造成不必要的负载。

7. 实施用于生产级监控的 Webhook

• 此步骤的目标：设置可靠的 Webhook 处理以接收实时部署通知。

• 目的：Webhook 消除了轮询开销，提供即时通知，这对于构建一个能够不延迟地将玩家移入游戏的响应式對局配對系统至关重要。

Webhook 是 Edgegap 在部署状态发生变化时向您的后端发送的 HTTP 回调。将它们看作是您的對局配對系统的推送通知。不需要经常去检查是否有事情发生，而是会在发生时立即被告知。

可用的 Webhook 事件

Webhook 有效负载包含与 /v1/status/{request_id} 端点相同的数据；您可以获得完整的部署信息，包括连接详细信息、区域和状态。

Webhook 要求

• 返回 HTTP 2xx：您的 Webhook 端点必须返回成功状态代码 (200-299) 以确认收到。任何其他状态代码或超时都标志着失败。

• 没有自动重试：Edgegap 不会重试失败的 Webhook 交付。如果您的端点已关闭或返回错误，您将错过该通知。这就是为什么您需要实施自己的重试逻辑并在后端维护部署状态的原因。

• 实现幂等性：尽管 Edgegap 不会重试，但网络问题或您自己的系统可能会导致您多次处理相同的 Webhook。设计您的 Webhook 处理程序以安全地处理重复通知，而不损坏您的状态。

最佳实践

• 使用 Webhook 来驱动玩家分配：这可以减少玩家等待的时间，并消除不断轮询状态的开销。在您的负载测试期间，测量从创建部署到玩家连接的速度。以下是典型的流程：

  • 对局形成，创建配置了 webhook_on_ready 的部署

  • 玩家在“对局开始”状态中等待

  • Webhook 到达您的后端：“部署 XYZ 已就绪”

  • 您的后端立即将连接详细信息发送给等待的玩家

  • 玩家连接，对局开始

• 存储部署状态：不要仅仅依靠 Webhook。在您的后端维护部署状态的数据库，以便在错过通知或系统重启后进行恢复。使用 Webhook 来更新此状态，但将可信来源保留在您自己的底层架构中。

• 避免频繁的轮询

8. 负载测试执行计划建议

• 此步骤的目标：创建一个结构化的、多阶段的负载测试，以验证部署管道的每个方面。

• 目的：尝试模拟您的发布时间表和玩家旅程，以确保在类似于发布首日的压力下，每个组件都能正常工作。

第 1 阶段：准备测试客户端

在创建部署之前，您需要有一些东西来创建它们。构建模拟您的對局配對系统行为的测试客户端：

• 模拟真实的對局配對流量，从而镜像玩家实际排队游戏的情况

• 当对局形成时，从您的后端生成部署请求

• 处理 Webhook 响应并相应地更新对局状态

• 跟踪所有部署生命周期事件以便稍后分析

这些测试客户端本质上是您生产對局配對后端的简化版本。它们不需要很强大，但必须准确地代表您的 API 使用模式。

第 2 阶段：执行部署创建递增

开始逐步创建部署，遵守速率限制并遵循符合实际的到达曲线。这个阶段测试了您随着玩家流量的增长而扩展部署创建的能力：

• 缓慢开始并逐步增加——避免无法反映真实玩家行为的瞬间突发高峰

• 通过均匀分配请求，来将速率保持在 API 速率限制内

• 遵循渐进曲线，模拟有机玩家到达（在第 10 节中有更多关于此的内容）

• 监控速率限制错误并在遇到 429 响应时调整步调

此阶段验证了您的部署创建逻辑能够处理预期的玩家到达率，而不会导致 API 过载。

第 3 阶段：跟踪部署就绪状态

随着部署的启动，监控它们何时准备好进行玩家连接：

• 对于就绪通知，主要依赖 Webhook（如第 7 节所述）

• 如果 Webhook 在您的测试设置中不可行，可以选择谨慎地轮询 /v1/status

• 测量每个部署的就绪时间——这直接影响到玩家的等待时间

• 跟踪错误率并调查未能达到 READY 状态的任何部署

如果您在此阶段看到部署时间较长或错误率较高，则需要在进一步推进之前进行调查。随着您扩展到整个生产负载，这些问题将会加剧。

第 4 阶段：模拟玩家连接（如果可能）

此阶段是可选的，但非常有价值。一旦部署报告 READY，实际连接模拟玩家以测试完整的管道：

• 启动游戏客户端机器人，使用部署的连接信息进行连接

• 跟踪连接成功率——一些部署可能会报告 READY，但连接仍然失败

• 测量从模拟玩家位置到其分配服务器的网络延迟

• 如果您的机器人可以执行基本的游戏内操作，请验证游戏功能

此阶段揭示了只有在真正的客户端连接发生时才会出现的问题。如果您无法实施完整的游戏客户端模拟，至少要测试与每个部署 IP 和端口的原始网络连接。

第 5 阶段：执行清理和验证

最后一个阶段验证您的部署生命周期管理：

• 随着模拟对局的完成，终止部署（参见第 5 节）

• 扫描未被正确清理的孤立部署

• 通过检查部署是否在所有预期的状态之间转移，来验证生命周期的正确性

• 分析您在所有阶段收集的数据，以确定瓶颈和故障

成功的清理阶段应该显示零个孤立部署，并确认您的系统在规模上正确地管理了完整的 创建-运行-删除 周期。

9. 模拟真实的玩家流量

• 此步骤的目标：设计能够准确反映真实玩家加入游戏对局并扩展游戏服务器部署方式的负载测试模式。

• 目的：与实际的流量模式保持一致，以产生有意义的洞察。如果您的测试与真实行为不符，您将无法在发布时发现潜在的真实问题。

关于负载测试，有一个至关重要的事实：合成压力测试不会揭示生产环境中的问题。

如果您立即创建 1,000 个部署，您并不是在模拟真实的发布，您只是在证明 API 可以使用 429 错误来拒绝您的请求。

需要避免的情况

避免以下不切实际的测试模式：

• 立即创建数千个部署：真正的玩家不会在完全相同的毫秒内到达

• 忽略對局配對流程：生产部署是在形成对局时创建的，而不是按定时器创建的

• 跳过部署清理：真正的对局结束并为新对局释放容量

• 仅测试短暂的突发状况：生产负载会持续数小时，从而揭示短期测试遗漏的问题

• 在没有后端编排的情况下运行测试：您的实际系统包括對局配對逻辑、队列和状态管理

这些模式可能会给系统施加压力，但它们并不能验证您实际的生产架构是否会起作用。

良好的负载测试模拟了什么

一个现实的负载测试模拟了这些行为。例如，使用 SteamDB 的 CCU 跟踪器与对比游戏进行对照。例如，PEAK 取得的巨大成功仍然需要几天时间才能扩展到其最高的 CCU 峰值，其最大增幅为在一天内完成了 40,000 CCU，而该天内的平均 CCU 与峰值 CCU 的对比为 20,000。

• 玩家到达率：玩家起初零星进入，然后在高峰期成群结队地到达。

• 对局创建频率：基于您的對局配對系统形成群组的速度

• 完整的部署生命周期：创建、就绪、玩家连接、对局持续时间和清理

• 可变的会话持续时间：一些对局很快，另一些则运行得更长

• 地理分布：玩家来自不同的区域，影响到部署位置

当您对这些因素进行建模时，您的负载测试就会成为对您的生产就绪状态的真正验证，而不仅仅是 API 压力测试。

10. 流量配置文件示例

如前所述，最可能出现的情况是，使用 SteamDB 匹配相同类型和项目范围内的对比游戏，并为同时发布的主机应用倍数（PlayStation 为 3-5 倍，XBOX 为 1 倍）。

既然如此，让我们来看看三种不同的规模场景。评估符合您预期发布流量的场景，或根据这些示例创建自定义配置文件

场景 A：独立游戏发布（200 个并发玩家）

推荐的测试计划：在 10 分钟内将部署从 0 逐渐增加到 5 个/分钟，然后持续 60 分钟。

场景 B：中等规模多人游戏（2,000 个并发玩家）

推荐的测试计划：在 20 分钟内将部署从 0 逐渐增加到 20 个/分钟，然后持续 90 分钟。

场景 C：大型活动/测试周末（10,000 个并发玩家）

推荐的测试计划：在 30 分钟内将部署从 0 逐渐增加到 50 个/分钟，然后持续 2 到 4 小时。

实施实际的递增曲线

无论您的规模如何，都遵循这样的渐进递增模式：

时间（分钟）→ 部署/分钟
0–10     → 0 → 5
10–20     → 5 → 15
20–30     → 15 → 30
30–60     → 维持在高峰值

这条渐进的曲线模拟了：

• 随着服务器在线的消息传播，有机玩家的到达

• 随着队列填满且对局开始形成，對局配對器预热

• 随着 Edgegap 扩展容量以满足需求，部署配置递增

• 随着流量模式的建立和优化，网络路由稳定

在您的部署时间中也加入一些随机性。不要在确切的秒边界上创建它们。真正的對局配對在对局形成的时间上具有自然差异。

11. 定义生产验证目标

• 此步骤的目标：建立明确的成功标准，以便您知道您的负载测试是通过了还是暴露了问题。

• 目的：需要具体的指标来确定您是准备好发布还是需要进一步优化。

一个成功的负载测试不仅仅是“运行而不崩溃”。您需要特定的性能目标来定义可接受的玩家体验。以下是您应该验证的关键指标：

• 对局创建延迟：这衡量了从“对局形成”到“部署 API 调用完成”所花费的时间。在这段时间里，玩家正在等待，因此将其保持在 5 秒以下可以维持良好的用户体验。

• 部署就绪时间：这在很大程度上取决于您的容器化游戏服务器启动并准备好连接的速度。在开发过程中优化您的容器启动时间——30 秒的启动优于 2 分钟的启动。

• 玩家连接成功率：99% 以上意味着几乎每个玩家都成功连接到他们分配的服务器。如果您看到连接失败，请调查这是网络问题、游戏服务器问题还是提供给客户端的连接详细信息不正确。

• API 速率限制饱和度：您应该在不达到速率限制的情况下完成负载测试。如果您收到 429 错误，您的部署请求模式太过于激进，在生产中也行不通。

• 孤立部署：零个孤立部署意味着您的生命周期管理工作正常。即使是一个孤立的部署，也暗示您的清理逻辑中存在一个漏洞，这会在规模上浪费资源。

使用负载测试数据来识别瓶颈、优化您的系统并再次测试。推迟发布远比在真实玩家面前面临底层架构故障要好得多。

12. 与 Edgegap 协调进行大规模测试

• 此步骤的目标：确保 Edgegap 的底层架构已准备好支持您的大规模负载测试。

• 目的：大规模的负载测试需要协调以确保获得准确的结果。

如果您的负载测试涉及相当大的规模，请不要只是开始猛击 API。提前通知 Edgegap，以帮助您准备我们的底层架构来妥善处理您的测试，就像大型发布一样。

何时需要提前协调

如果您的测试涉及以下情况，请通知 Edgegap：

• 每秒超过 20 次部署并持续一段时间

• 持续数小时的负载（高峰期 2 小时以上）

• 跨越多个地理区域的多区域同步流量

• 临近发布日期的测试，您需要保证测试结果

通过 Dashboard → Tools 区域或通过 Edgegap Discord 社区联系 Edgegap。提供关于您预期的部署率、测试持续时间和目标区域的详细信息。

协调带来了什么

当您提前协调时，Edgegap 可以：

• 在您将要测试的区域内预先扩展容量，确保服务器立即可用

• 如果您的测试确实需要更高的吞吐量，可以临时提高速率限制

• 监控底层架构准备情况并主动解决任何容量限制

• 如果您在测试期间遇到意外问题，可以提供技术支持

此协调可确保您的测试能够准确地反映生产性能，而不是测量 Edgegap 的冷启动扩展能力。最重要的是验证您的系统。

13. 推荐的负载测试工具

为了执行您的负载测试，我们推荐两种行业标准工具：Apache JMeter 和 k6。

这两者都是专门为负载测试 API 而构建的，并且可以在遵守速率限制的同时模拟现实的部署请求模式。

• Apache JMeter：JMeter 提供了一个用于设计复杂测试场景的可视化界面，这使其非常适合那些更喜欢基于 GUI 进行测试配置且希望在不编写代码的情况下拥有内置报告控制面板的团队。

• k6：k6 使用 JavaScript 来编写测试脚本，并且擅长现代 CI/CD 集成，这使其非常适合那些希望将负载测试与代码一起进行版本控制并在部署管道中自动进行测试的团队。

结论

对多人游戏底层架构进行负载测试是您发布前的一个重要里程碑。

这是您在问题影响到真实玩家之前，发现并解决问题的机会。通过遵循这种综合方法，您不仅可以验证您的服务器是否可以处理负载，而且可以验证您的整个從對局配對到游戏玩的管道在大规模上是否可靠地工作。

祝您发布顺利！如果您有任何问题或需要负载测试策略方面的协助，Edgegap 团队随时可以在 Discord、电子邮件或 Slack（视要求而定）上提供帮助。