导语：近期经历了一系列的性能测试，涵盖了 Web 服务器和游戏服务器的领域。在这篇文章中，我将会对游戏服务端所做的测试进行详细整理和记录。需要注意的是，本文着重于记录，而并非深入的编程讨论。在这里，我将与您分享这段时光的见闻，希望能够为您呈现一个全面而有趣的视角，谢谢您的关注。
为什么要做游戏服务器的性能测试？想想平时有没碰到哪些宕机卡顿场景。说不定就是服务器引起的。
用户体验保障： 游戏服务器性能直接影响玩家的体验。如果服务器性能不足，游戏可能会出现延迟、卡顿、掉线等问题，影响玩家的乐趣，甚至可能导致玩家流失。
稳定性验证： 在高并发情况下，游戏服务器可能会面临各种挑战，如峰值负载、请求堆积等。性能测试可以验证服务器在不同负载情况下的稳定性和可靠性，帮助开发人员发现潜在的问题并加以解决。
服务器容量规划： 通过性能测试，开发团队可以了解服务器在不同负载下的性能表现，从而做出合理的容量规划。这有助于避免服务器过剩或不足的情况，提高资源利用效率。
性能优化： 通过性能测试，可以识别服务器性能瓶颈和瓶颈原因。开发人员可以根据测试结果进行针对性的优化，提升服务器的性能和响应速度。
应对突发情况： 在游戏发布或活动期间，服务器可能会面临突发的用户激增，如推出新内容、举办活动等。性能测试可以模拟这种情况，帮助开发团队准备应对措施，保证服务器在压力下仍能正常运行。
节省成本： 通过性能测试，可以有效地发现并解决问题，减少后期维护成本。同时，避免了因服务器性能问题引起的用户流失，有助于提高游戏的盈利能力。
主要是下面这些，还有进程，线程这些，就不一一列出
Python 一直以其简洁和强大而闻名，版本 3.10.9 带来了一系列令人兴奋的特性。我们将在这个框架中体验到这些特性的魅力，从而更高效地实现我们的目标。
Ray： 这个库为我们提供了分布式执行的能力，让我们的任务可以在多个进程和线程中并行执行，从而极大地提高了效率。
Pykka： 作为一个轻量级的 Python 库，Pykka 为我们提供了优雅的多线程编程方式，使得线程间的通信和协调变得更加简单。
Flask： 作为一个微型的 Web 框架，Flask 不仅简化了我们构建 Web 应用的过程，还为我们提供了扩展性强的组件。
Sproto： 这个库让我们能够更加便捷地进行数据的序列化和反序列化，从而在通信过程中更加高效地传递数据。
Redis： 作为一个高性能的缓存数据库，Redis 将为我们的应用提供快速的数据访问能力，从而提升整体性能。
在技术的道路上，一个稳定且可控的环境是不可或缺的。我们将在 Ubuntu Docker 容器中搭建我们的实验环境，这将确保我们的测试和分析更加准确可靠。
云服务器 A 上承载了众多游戏服，而云服务器 B 则承载多个中心服和跨服。这里，我们会模拟不同负载情况，为了更好地探索，将以批次的形式进入 N 个游戏服，紧随其后是新手测试，我们将一直持续到特定任务 ID 的终结。
我们的目标是验证注册、创角和登录的表现，按需求，在 1 分钟内承受 2000 的导量，这是我们的挑战。令人欣慰的是，注册、创角和登录的数据显示没有问题，成功率竟然高达 100%！
我们深入挖掘了玩家的登录耗时数据，发现存在一些问题，最长的耗时竟然达到了 35 秒。现在，让我们一起揭开这些耗时长的面纱，找出问题的源头。
为了针对性地优化，我开始统计各种协议的响应时间。通过这些数据，我们可以找到那些耗时较长的环节，并将其交给开发团队进行深入优化。
我们对已经创角的玩家再次登录进行了观察，发现黄色和红色角色都是已创角的。这提示我们可能存在创建角色耗时长的问题。在进一步的调查中，我们发现问题出在了数据写入数据库上，导致了耗时问题。
我持续测试了半小时，观察了游戏服的 CPU 和内存表现。不同公司标准不同，而对于我司，单核 CPU 达到 100%、内存使用 3G，是服务器的承载上限。
这次，我们将进入一个充满挑战的领域，探索大型玩法场景的负载极限。
在这个玩法中，一群玩家将齐聚于同一场景，迎接着 Boss 的挑战，彼此间展开激烈的战斗，不仅能够互相击杀，还有机会获得积分。直至时间结束，他们会走出场景，留下属于战斗的记忆。这次，我们要测试的是在这样的场景中，服务器和客户端的性能表现。
我们的目标是找到这个场景能够支持的最大玩家人数，让他们在同一场景中展开战斗。接下来，我们将分析性能数据，从中得出场景的负载极限。这将为我们后续的优化和规划提供宝贵的信息。得出一个场景极限后，超出的则分流到多个场景。
这次的标准与之前的新手测试有所不同。在新手测试中，我们的服务器已经达到了百分之百的极限。而在这次的跨服测试中，我们的极限提高到了百分之二百。然而，这个标准的确立并不仅仅取决于服务器资源的分配，还与服务器整体架构紧密相连。寻找服务器和玩家数量之间的平衡点。
我们注意到上图 CPU 的异常高负荷与同场景战斗的人数和频繁的战斗逻辑运算有着密切关系。在庞大的人数和频繁的战斗计算下，CPU 不堪重负，面临过载的问题。
我们进一步研究了协议数据量，令人惊讶的是，单个机器人仅在 1 分钟内就接收了 4 万条数据。这些海量的数据传输不仅增加了网络负担，也加重了服务器的压力，进一步加剧了 CPU 的过载情况。
百人同场景战斗所带来的全地图实时同步，确实让服务器承受难以想象的压力。为了解决这个问题，我们采取了局部广播 - 九宫格的策略。这种方式有效地减轻了服务器的负担，让战斗同步变得更加可控。
在这次的技术探索中，我们深入了解了 CPU 过载的原因以及其背后的数据关系。通过切换战斗同步策略，我们正在逐步找到解决之道。技术世界充满了无限的挑战和机会，让我们继续前行，一同探索未知的领域。
