本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
GAMEOPS03-BP03 尽早并经常进行负载测试
负载测试是在系统上模拟真实交通以评估其可靠性和性能的过程。
在未建立这种最佳实践的情况下暴露的风险等级：高
实施指导
负载测试是制定资源性能基准和了解系统容量的关键因素，这可以指导财务预测、架构设计、资源分配、自动扩展配置和启动后的预扩展活动。其他优点包括：
-
优化的基础架构：资源可能过度或不足。了解所需的资源将降低成本并减少需要管理的基础架构。
-
可扩展性就绪：某些机制和功能可以推动用户快速进入游戏。知道何时以及如何扩大规模可能是适当满足不断增长的需求和失去玩家之间的区别。使用负载测试结果来准备包含不同扩展级别的系统阈值、警报点和关键警报点的运行手册。
-
更高质量的代码：服务之间的过度串扰、未批处理的数据库调用、效率低下的算法、内存泄漏和服务降级问题等问题有时更容易大规模识别。
-
行为验证：在测试中注入不同类型的失败可以验证系统的预期行为或发现需要纠正的错误处理问题。
理想情况下，开发人员应在整个开发过程中的多个时间点进行负载测试，因为每个时刻可以产生不同的好处：在早期，他们指导架构决策和重构工作，同时进行更改既便宜又简单。在每次冲刺或迭代结束时，他们使用最新的特性和功能来验证应用程序的性能。
在部署到生产环境之前，模拟预期的实际使用模式的大规模负载测试证实了系统处理生产工作负载的能力。部署后，定期负载测试会监控系统的性能，并确定随着时间的推移可能出现的变化或瓶颈。
要模拟玩家流量，你需要轻量级客户端或机器人来模拟游戏客户端流量，并与游戏后端进行交易以模拟真实玩家的行为。这些数据通常通过游戏日志和由人为驱动的 QA 测试生成的数据以及真实世界的有限规模 alpha 或 beta 测试获得，在这些测试中，真实玩家被邀请玩游戏的抢先体验版本。
必须在操作运行手册中记录系统的行为，以帮助排除将来可能出现的故障，并保留性能指标，以便将来的负载测试与之比较。还建议让人类 QA 人员在游戏进行负载测试时对游戏进行测试，因为他们可能会发现机器人无法识别且指标无法反映的问题。
AWS 故障注入服务
实施步骤
-
使用 Kubernetes-Bases 游戏负载测试指南设置分布式负载测试环境
。 -
使用提供的部署文件在 EKS 集群中自定义和部署 Locust 控制和工作容器，从而实现可扩展和可管理的负载生成。
-
在操作运行手册中记录负载测试期间的系统行为和指标，以帮助将来进行故障排除并建立性能基准。
-
使用故障注入实验来模拟现实世界的中断，发现系统性能、可观测性和弹性方面的隐藏问题。
