本指南解释了如何使用哪些工具在Edgegap平台上通过Edgegap API运行负载测试在线多人游戏，特别是

对局配对和游戏服务器部署。

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

涵盖的主题（按章节）：

1. 先决条件

2. 对局配对流程及部署计划

3. API速率限制

4. 部署API

5. 部署生命周期管理

6. 部署状态

7. Webhooks

8. 负载测试执行计划

9. 真实流量建模

10. 流量概况

11. 流量目标

12. 何时引入Edgegap团队

13. 推荐工具

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

目标受众

本文件面向后端工程师、运维团队及为生产发布做准备的工作室。

目标时间表

尽管运行负载测试从来没有理想的时间，但我们建议在发布前几周进行一次演练，以评估您的多人游戏架构中的任何弱点。

请参阅我们的多人游戏发布前清单以获取发布前的建议时间表。

什么是多人游戏负载测试及其重要性

负载测试是一种性能测试，它模拟大量并发玩家（“CCUs”）以评估多人游戏的基础设施在压力下的性能，包括对局配对和游戏服务器部署。

通过在发布前进行负载测试，可以识别出一些问题，例如内存泄漏、数据库查询瓶颈、低效的网络代码，并在发布前修复它们。

正如我们过去常常提到的，如果无法做好准备而无法在发布时无缝扩展，其后果可能会令游戏开发者损失数百万美元，因为游戏无法访问（即便您在发布前投入了AAA级别的资源去避免这一点）。

因此，工作室使用经过验证的Edgegap游戏服务器编排，可在60分钟内扩展到1400万并发玩家，期间每秒持续进行40次部署。因此，在第一个小时内乃至更多时间内都处于良好状态。 

1. 先决条件

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

• 目的：确保您的测试环境与生产配置相匹配。

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

在进行负载测试之前，请确保您已具备以下条件：

• 已设置计费的Edgegap账户

• 一个API令牌

  • 注意：您的API令牌将包含在每个请求头中，格式如下：Authorization: token <your-token>。请确保此令牌安全，因为它对您的Edgegap资源具有完全访问权限。

• 一个封装为Edgegap 应用版本的容器化游戏服务器

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

请注意，我们的文档中提供了API参考。

2. 理解对局配对及部署计划

• 此步骤的目标：映射出您的对局配对系统如何将玩家活动转换为部署请求。

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

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

玩家登录→对局配对队列→发现对局→创建部署→服务器就绪→玩家连接→对局运行→删除部署

关键的见解是每场对局需要正好一个部署。这种一对一的关系是您容量规划的基础。

计算部署需求

让我们来做计算。如果您的游戏支持每个服务器实例N名玩家，您可以准确计算出可能需要多少部署：

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

估计玩家基础的扩展

使用每个总玩家的部署数，下一步是估计这些部署随着时间的变化（即“扩展”）。

这就是大多数游戏开发者在负载测试中犯的错误，他们在短短几分钟内对整个玩家基数进行测试，过高地估计每秒的部署数量以“扩展”到其发布目标。

例如，世界上最流行的游戏，Fortnite，曾一度达到1430万并发用户的峰值，估计每秒100个部署。然而，Fortnite在其日益顶峰时平均每秒30-40次部署。玩家基于其日常生活（睡觉、上班）如潮水般进出游戏。因此，即便游戏在全球范围内同时发布，负载测试应该在60分钟内达到其发布峰值并发用户的25-50%，才能切合实际。

即公式为：（所需部署数 * 估计峰值百分比） / 3600秒 = 负载测试的每秒部署目标

3. 尊重API速率限制（关键）

• 此步骤的目标：了解和工作在服务器部署的速率限制范围内。

• 目的：确保您的负载测试反映现实世界的限制。避免在测试过程中触及速率限制，因为这样可能掩盖真正的性能问题。虽然不太可能，但如果您在生产中遇到相同的限制，您的测试必须考虑到它们。

Edgegap为确保系统稳定性，实施了涵盖整个组织的速率限制。这些限制适用于整个组织。

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

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

当您超过这些限制时，API会返回HTTP 429 – 请求过多。确保不要触犯这些限制，以避免此错误消息。

速率限制合规的最佳实践

为了避免超出限制并确保性能可靠：

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

• 在429响应中始终遵守Retry-After头。它会告诉您具体等待多长时间后重试。

• 通过随时间分布部署请求来避免突发尖峰。渐进式隆起更为现实。

• 使用webhooks而不是轮询来跟踪部署状态。这会显着减少您对状态端点的使用。

⚠️重要提示：如果您计划进行大规模负载测试（在几个小时内持续负载或高部署速率），请事先与Edgegap支持小组协调。他们可以暂时提高您的限制并预先扩展容量以确保准确的测试结果。

4. 通过API创建部署

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

• 目的：获取API调用是部署流程的核心。它可确保您的服务器在所有玩家的最佳位置进行部署并接收正确的webhook通知。

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

创建部署端点

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

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

必需的HTTP头：

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": ["对局配对", "负载测试"],

"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"

}

}

理解关键参数

• 用户数组：这是Edgegap确定您部署的最佳地理位置的方式。包括将连接到此对局的玩家的IP地址。系统使用此信息来选择可以最大程度减少所有参与者延迟的边缘位置。

• webhooks：强烈推荐使用，而不是轮询。Webhooks可在部署准备就绪或遇到错误时提供即时通知，让您可以立即将玩家移入比赛，而无需持续检查状态。

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

5. 管理部署生命周期

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

• 目的：未正确终止的孤立部署将增加您的成本，消耗容量，并导致您的负载测试结果毫无意义，因为您需要查看系统如何处理完整的创建-运行-删除周期。

负载测试中常见的错误是仅关注部署创建而忽视清理。在实际的生产环境中，对局结束会终止服务器以避免超支。您的负载测试必须模拟此完整的生命周期（并为您节省负载测试的费用）。

从后端删除部署

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

端点

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

HTTP头

Authorization: token <your-token>

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

替代：自我终止（即让游戏服务器决定）

这里有一种替代方法，给予您更多的灵活性：每个部署都包含一个独特的删除URL和令牌，允许游戏服务器在适当时自行关闭。这在游戏逻辑最了解何时真正结束比赛时尤其有用。

例如，您的游戏服务器可能会等所有玩家断开连接后，上传赛后统计数据，并保存任何回放，然后触发自身的终止。此方法可确保清理过程中没有任何数据丢失。

有关自我终止的更多信息，请参阅Edgegap的部署生命周期文档。

提醒：未能终止服务器的代价

如果未能正确删除部署将导致：

• 显著增加您的成本，因为您为闲置的服务器付费

• 使您的负载测试结果失衡，使您看起来需要更多的容量而实际上不需要

• 创造运营问题，因为您的仪表板充满了无用的部署

在进行负载测试期间，使用Edgegap的分析进行监控，以检测任何没有被正确清除的部署。

-> 这些孤立的部署是您的生命周期管理在发布前需要调整的红色信号。

6. 跟踪部署状态

• 此步骤的目标：了解如何监测部署准备情况而不过度使用API进行状态检查。

• 目的：准确知道何时部署准备好接受玩家是对局配对流程的关键。然而，过度轮询会触发速率限制，并不符合生产最佳实践。

创建部署后，您需要知道什么时候可以接受玩家连接。有两种方法：轮询状态端点或使用webhooks。一个显著更优于另一个。

webhooks：正确的方法

不要每秒询问“准备好了吗？”，让Edgegap在有变动时立即通知您。这就是webhooks做的事情，它们是生产系统推荐的方法（参见步骤7）。

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

最佳实践：使用webhooks作为您的主要通知机制。将状态端点保留用于特殊情况下的手动检查部署状态- 也许在调试或处理少见的边缘情况时。

状态端点（精简使用）

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

速率限制：10请求/秒

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

• 状态.DEPLOYING – 服务器正在启动

• 状态.READY – 服务器已准备好接受玩家连接

• 状态.ERROR – 部署过程中出现了问题

虽然此端点可用，但不断轮询数百个部署很快会造成问题。您将迅速用尽速率限制，并在API上制造不必要的负担。

7. 实施生产级监控的Webhooks

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

• 目的：webhooks消除了轮询开销，提供即时通知，这对于构建能快速将玩家移动到游戏中而不延迟的响应对局配对系统大有裨益。

webhooks是Edgegap在部署状态更改时发送到您后端的HTTP回调。将它们视为您对局配对系统的推送通知。不是时刻查看是否发生了什么，而是事情发生时立即通知您。

可用的webhook事件

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

Webhooks要求

• 返回HTTP 2xx：您的webhook端点必须返回成功状态码（200-299）以确认收件。任何其他状态码或超时均表明失败。

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

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

最佳实践

• 使用Webhooks驱动玩家分配：玩家等待的时间和消除持续状态轮询的开销。在您的负载测试期间，测量从部署创建到玩家连接的速度如何。以下是典型的流程

  • 形成对局，部署时配置webhook_on_ready

  • 玩家在“比赛开始”状态中等待

  • webhook到达您的后端：“部署XYZ已准备好”

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

  • 玩家连接并比赛开始

• 存储部署状态：不要仅依赖Webhooks。在您的后端维护部署状态的数据库，以恢复错过的通知或系统重启。使用webhooks更新这种状态，但保持自己的基础设施中的真相源。

• 避免激进的轮询

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

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

• 目的：尝试模拟您的发布时间线和玩家旅程，以确保每个组件在类似于发布当天的压力下工作。

阶段1：准备测试客户端

在您能创建部署前，您需要创建一个东西来进行它们。构建测试客户端以模拟您的对局配对系统的行为：

·       模拟现实世界的对局配对流量，镜像玩家如何实际上排队进行游戏

·       生成部署请求，当形成比赛时从您的后端生成

·       处理webhook响应并相应更新比赛状态

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

这些测试客户端本质上是您生产配对后端的简化版本。它们不需要那么健壮，但它们必须准确代表您的API使用模式。

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

逐渐开始创建部署，尊重速率限制并遵循现实到达曲线。此阶段的测试是验证您的部署创建能力随着玩家流量的增长而扩展：

• 从慢开始，循序渐进-避免不反映真实玩家行为的即时波动

• 停留在API速率限制范围内，通过分配均匀分布请求

• 遵循逐步曲线，模拟有机玩家到来（更多见第10节）

• 监控速率限制错误，如果遇到429响应则调整步调

此阶段验证您的部署创建逻辑是否能够处理您的预期玩家到达率而不压迫API。

阶段3：跟踪部署就绪状况

随着部署的启动，监控何时可以接收玩家连接：

• 主要依靠webhooks进行就绪通知（如第7节所讨论）

• 可选地略微轮询/v1/status，如果webhooks不适合您的测试设置

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

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

如果在此阶段看到长时间的部署时间或高错误率，则需要在继续之前进行调查。这些问题将随着您扩展到全面的生产负载而加剧。

阶段4：模拟玩家连接（如可行）

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

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

• 跟踪连接成功率—某些部署可能报告就绪，但仍然连接失败

• 测量玩家位置到其指派服务器的网络延迟

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

此阶段披露的只是一些真实客户端连接时才会出现的问题。如果您无法实现全游戏客户端的模拟，至少测试原始网络连接到每个部署的IP和端口。

阶段5：执行清理和验证

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

• 终止部署，随着模拟比赛完成（见第5节）

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

• 核实生命周期的正确性，通过检查部署是否经过所有预期状态

• 分析在所有阶段收集的数据，识别瓶颈和故障

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

9. 模拟真实玩家流量

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

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

关于负载测试的一个关键事实是：合成压力测试无法揭示生产问题。

如果您瞬间创建1,000个部署，您不是在模拟真正的发布，而只是证明API可以拒绝您的请求并返回429错误。

应避免哪些情况

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

• 瞬间创建数千个部署：真实玩家不会在完全相同时刻到达

• 忽略对局配对流程：生产部署会在形成比赛时创建，而不是定时器上

• 跳过部署清理：真实比赛结束并为新比赛释放容量

• 只进行短暂爆发测试：生产负载会持续几个小时，揭露短测试无法发现的问题

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

这些模式可能会施压于系统，但它们并不能验证您的真实生产架构是否能正常工作。

良好的负载测试模拟了哪些行为

真实的负载测试展示了这些行为。例如，与比较游戏对齐使用SteamDB的CCU跟踪器。例如，PEAK的巨大成功仍然用数天时间扩展到其最高CCU峰值，并在一天内实现最大增量的40,000 CCUs，且其当天内的平均CCU为20,000而不是峰值。

• 玩家到达率：玩家最初缓缓进入，然后在高峰期成群到来。

• 比赛创建频率：基于您的配对系统多快能形成组

• 完整的部署生命周期：创建、就绪、玩家连接、比赛时长及清理

• 可变的会话时长：有些比赛是短暂的，其他比赛运行更长时间

• 地理分布：从不同地区来的玩家影响部署位置

当您模型化这些因素时，您的负载测试成为提升生产就绪的真正验证，而不仅仅是一个API压力测试。

10. 流量概况示例

如前所述，最可能的情景将是匹配一个比较标题在相同的类别和项目范围内，使用SteamDB并为同时的控制台发布应用一个乘数（3-5倍用于PlayStation，1倍用于XBOX）。

话虽如此，让我们来看看三种不同规模的情景。评估与您预期的发射流量匹配的场景，或基于这些示例创建定制的概况

情景A：独立发布（200个并发玩家）

推荐测试计划：在10分钟内从0增加到5次部署/分钟，然后保持60分钟。

情景B：中型多人游戏标题（2000个并发玩家）

推荐测试计划：在20分钟内从0到20次部署/分钟递增，然后维持90分钟。

情景C：大型活动/测试周末（10000个并发玩家）

推荐测试计划：在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错误，则您的部署请求模式过于激进，也将无法在生产中正常工作。

• 孤立的部署：零孤立表明您的生命周期管理工作正常。即使只有一个孤立的部署，也意味着您的清理逻辑中存在一个Bug，该Bug将在规模上浪费资源。

使用负载测试数据识别瓶颈，优化您的系统，并再次测试。推迟发布如果面对真实玩家基础设施问题总比更好。

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

• 此步骤的目标：确保Edgegap的基础设施准备好支持大规模的负载测试。

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

如果您的负载测试涉及大规模，切勿仅仅开始在API上施压。向Edgegap提前通知以帮助您准备我们的基础设施以正确处理您的测试，正如它将推出大规模发射一样。

何时提前协调

如果您的测试涉及，请通知Edgegap：

• 超过20个部署每秒的持续负载

• 持续负载时间超过数小时（高峰期超过2小时）

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

• 测试计划在您的发布日附近安排，您需要保证的结果。

通过控制面板→工具部分或通过Edgegap Discord社区联系Edgegap。提供关于预期部署率、测试持续时间和目标区域的详细信息。

协调使能什么

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

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

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

• 监测基础设施的就绪情况，并主动处理任何容量限制

• 在测试过程中遇到意外问题时提供技术支持

这种协调确保您的测试准确地反映生产性能，而不是衡量Edgegap的冷启动能力。主要目标是验证您的系统是否能正常运行。

13. 推荐的负载测试工具

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

这两个工具都是专为负载测试API而构建，并可以模拟现实的部署请求模式，同时尊重速率限制。

• Apache JMeter：JMeter提供了可视化界面，用于设计复杂的测试场景，使其非常适合偏好图形界面测试配置并希望无需代码的内置报告仪表板的团队。

• k6：k6使用JavaScript 进行测试脚本，并且在现代CI/CD集成方面表现出色，非常适合希望在代码旁边版本控制其负载测试的团队，并在部署管道中自动化测试。

结论

为多人游戏基础设施进行负载测试是发布前的关键里程碑。

这是您发现并在影响真实玩家之前修复问题的机会。通过遵循这种全面的方法，您不仅会验证您的服务器是否可以处理负载，还会验证从对局配对到游戏流程整个管道在规模上也能可靠地工作。

祝您的发布一切顺利！如果您对负载测试策略有任何疑问或需要帮助，Edgegap团队将在Discord、电子邮件或在Slack（按需提供）上随时为您提供帮助。