People Mountain People Sea - 探索MMO在虚幻引擎上的实现(服务器篇)

比眉伴天荒 2022-08-30 11:28 113阅读 0赞

**这是【游戏开发那些事】第23篇技术文章**

前言：本文来自吕文伟老师的知乎专栏——《游戏开发杂谈》（内容略有调整）。吕老师是我上个公司的技术专家，从业近20年，在图形渲染、网络架构以及性能优化上都有着非常深厚的功底。

[**上一篇文章**][Link 1]我们探讨了UE4制作MMO时，客户端上潜在的性能瓶颈与优化思路。Skinned Instancing虽然性能不错但是有着诸多不便，而且通过测试发现除了渲染外移动计算也有着相当大的开销，所以还是尽可能考虑并行的方式进行处理。

不过实际操作中，并行**并不是像动画多线程处理AnimationGraph那样，不做任何牺牲，简单的把移动的逻辑拿到其他线程计算就可以了**。这样不同线程在更新PhysScene的时候，可能会由于PhysX读写锁的问题产生不确定的等待时间，同时还有很多TickFunction的逻辑在WorkerThread里面也不一定能保证线程安全。所以建议先深入理解PhysX引擎的底层更新逻辑，了解PhysScene中物理体的更新逻辑，梳理清锁的位置，然后在这个基础上有取舍的进行优化（如调整其他线程物理更新时机、对Dynamic的PxRigidActor做一些特殊处理，允许部分的Penetration等），当然也可以考虑实现一些特殊的加速结构处理物理碰撞查询等。

**一些PhysX的参考资料：**

https://docs.nvidia.com/gameworks/content/gameworkslibrary/physx/guide/Manual/GeometryQueries.html

Physx官方文档

https://zhuanlan.zhihu.com/p/60733992 Physx的多线程框架解析

https://zhuanlan.zhihu.com/p/111458039 Physx在UE4上的架构解析

https://zhuanlan.zhihu.com/p/352425260 UE4 物理引擎运作流程剖析

https://papalqi.cn/ue4-%E7%89%A9%E7%90%86%E7%B3%BB%E7%BB%9F%E5%AE%9E%E7%8E%B0/ UE4 物理系统实现

![807e2756557c80e1b5f9b4843bfe7819.png][]

▷▶动画系统可以设置多线程优化

客户端处理完后，我们接下来关注**服务器上的性能问题**。经过两个星期左右的紧张研发，我们已经将NetDriver的ServerReplicateActors以及ReplicationGraph的ServerReplicateActors功能全部做好并行化改造，而且通过了多次的压力测试，结果显示它对性能的提升意义重大。这个研发速度也超乎了我的预期，之前以为需要投入1个多月的时间才能完全弄好，但由于新版本UE4引擎在代码结构上变得更加的清晰，不同NetConnection之间数据的依赖性较弱，所以整个改造过程几乎没有遇到太多的障碍。

我们先来看看服务器端的两个性能热点，其中之一就是上面提到的ServerReplicateActors。为什么它会成为性能的瓶颈，在我其他的文章里已经做过分析，核心问题主要集中在**属性的比较，属性的序列化，以及数据包的发送**等几个方面。虽然每一个ActorChannel所消耗的CPU时间看似微不足道，但集腋成裘，当NetConnection每帧需要处理几千个ActorChannel的复制时，问题就凸显出来了。（这里可能考虑Connection并行的方式进行优化）

![513f830f99442009f3a69a422ac8367e.png][]

▷▶UE4的序列化数据包结构

不仅网络状态的同步侵占了可观的CPU时间，角色的移动和动画处理也会严重的影响到帧率，因为服务器端执行了与客户端类似的大部分逻辑。关于如何优化角色的移动和动画计算，我在前一篇文章已经做过一些解释，最主要的方法依然是要发挥多核的优势。

但是我们在服务器端却碰到了一个意想不到的问题，本以为处理后它会像客户端那样，所有相关的TickFunction被安排在不同的工作线程里执行，可拿到性能统计数据后，我发现**服务器端的移动和动画组件的TickFunction居然还是全部执行在主线程里。**不过经过调试分析很快就定位到了原因，那是由于与客户端不同，服务器端的移动组件会依赖AIController的TickFunction，而这个TickFunction默认情况下并不是异步执行的，所以它会导致它的所有后续任务都被迫执行在主线程里，即便那些后续任务配置成能够运行在任意线程里也于事无补（TaskGraph的特性）。

![15cd31e5a326ffc54705d0119d8c05bc.png][]![064bd6d92eb865ffda0d80c6b601b41f.png][]

随后，当我们将AIController的TickFunction修改成允许运行在任意线程里时，那些按理本应该运行在工作线程里的TickFunction**仍旧执行在主线程**。这完全出乎我的意料，通过查看TickTaskManager的代码，很快也找到了其中的原因。由于PathFollowingComponent的TickGroup默认情况下被设置成**TG\_DuringPhysics**，而其他TickFunction的TickGroup都是**TG\_PrePhysics**，TickTaskManager会在QueueTickFunction时自动将前置TickFunction的**TickGroup设置传播给后续的TickFunction**，因此PathFollowingComponent后续的TickFunction自然只能运行在主线程上了。一个NPC的TickFunction的执行依赖链如下所示:

![0bef8ff90bbdf9eba1b8cd399a07f9a8.png][]

上图的所有Component和Actor的TickFunction都需要做一样的配置。解决完上面的问题，接下来我们来看看ServerReplicateActors并行后的效果如何，下图是我们第一次的测试结果。

![221314e56234da5b4b84d5dd7f42b705.png][]

▷ ▶第一次并行优化后的服务器 性能结果

很明显，每帧的CPU时间并没有发生太多的变化，依然长得可怕，平均下来要花费60多毫秒。一个有趣的发现是主线程的属性复制任务执行时间很短，不到六毫秒，而工作线程里的相同任务却都用了60毫秒以上。因为结果实在太反直觉，我希望找到真正的原因，于是随后又做了多次的实验，终于获得下图所示的统计数据，真是一语惊醒梦中人。

![8dd9691d14869c9e5153a745fa565860.png][]

你看到那些红彤彤的Bar了吗？魔鬼就藏在里面。熟悉VTune的小伙伴估计下意识就能反应过来，这是由于**同步锁**导致的问题，红色的区域表示CPU在Spin，也就是空转，它极有可能是在等待互斥锁的释放。看看开销排行前几名的函数，里面有**CriticalSection（准确的说应该是临界区）**，不用问它就是罪魁祸首，但拥有这个互斥锁的临界资源到底是谁呢？位于CriticalSection之后的**FMallocBinned2**非常可疑，它是UE4的默认全局内存分配器，按道理这个分配器不会给我们惹麻烦，毕竟它的使用频率那么高，要出问题早就暴露了。后来通过仔细研读代码，总算是找到了解决方案。其实FMallocBinned2已经考虑到多线程使用的场景，**为了保护全局共享的内存池，它每次分配和释放内存时都会进入一个互斥锁。**而我们的属性复制函数里会频繁的分配和释放内存，于是互斥锁就让本该同时执行的逻辑变成了顺序执行，因此我们才有之前的结果，并行跟不并行差异不大。那是不是就无药可救了呢？显然不是，FMallocBinned2里面有一个FPerThreadFreeBlockLists的数据结构，它专门是用来解决这类问题的。通过给每个线程安排一个独占的小内存池，从而避免了进出互斥锁。当然这对于分配大尺寸的内存来说并不适用，幸运的是刚才我说的属性复制函数用到的内存都是小内存，所以很符合FMallocBinned2的假设。如果想**在工作线程里开启独立的Pool**非常简单，手动调用函数FMemory:: SetupTLSCachesOnCurrentThread()就可以了。接下来让我们检视一下修改后的性能统计数据，

![15e1337e4f7d6f91d1c47a8196c1c31e.png][]

![5a71db902132172eac7fe728aa522103.png][]

结果相当令人满意，工作线程的帧耗时已经成功降到了6毫秒左右。

当我们改造完ReplicationGraph后又做了性能数据的采样，从下图可知，NetConnection在多个线程里同时进行着属性的复制工作，那段时间里CPU的利用率非常高，这基本符合我们的预期。而且我们还专门开启了**PushModel**的特性，用以减少不必要的属性复制前的比较操作。但效果并没有像Epic官方说的那么神奇，性能上稍微有些提升而已。请注意并不是所有的引擎内建的可复制属性都使用了PushModel，例如ReplicatedBasedMovement依旧走的是常规的流程。值得一提的是**使用MarkPropertyDirty标记成脏属性的变量仍然需要进行比较**，对于原生的数据类型来说是没有必要的，例如float，int等，当然自定义的数据类型则另当别论。

![3f865a6a9ada84d305c275acd2074292.png][]

除了属性的比较和序列化，我怀疑SendBunch也消耗了过多的CPU时间，但根据下图的采样数据显示，SendBunch的执行时间远比ReplicateProperties短很多。

![feeaaf786e19bb71e66a929b22e6261a.png][]

> 这里说些题外话，一开始我们在做多线程的属性复制功能时就担心FSocketBSD::SendTo这个函数是否是线程安全的。因为UE4的服务器端只创建了一个Socket，它既用来接收不同客户端传输过来的Packet，又用来发送Packet给不同的客户端。当多线程做属性复制的逻辑时就会有概率在同一时刻调用sendto的接口，如果函数内部没有做保护，就会把错误的数据发送给客户端。但是经过反复的测试，发现似乎一切都很正常，看来我是多虑了。

如下图所示，平均下来每一个NetConnection的复制时间大概在3ms左右，这个值依然不理想，我希望能降到1ms以内，这样在有限的预算内，能让单个硬件线程承载足够多的玩家，同时减低运营的成本。上图还揭示了一个未来改进的方向，**那就是把Bubble尽量的填满**，因为CPU的平均利用率还不是太高，很多时间段内CPU的核其实是没有什么事情可做的。至于如何填充空泡，那就需要重新拆解任务了，目前我们的属性复制任务的并行模式还是Lockstep的，以后最好能让一些子任务变成Async的形态(将任务延迟到下一帧执行，与其他Lockstep的任务能在时间上发生重叠，这同主线程和渲染线程的关系非常的类似，我称之为削峰填谷)，例如组装Packet这项任务就是一个突破口，包括对其压缩和加解密的处理。

![285b0ebe32c87932d9582706b9c6af8c.png][]

最后让我们看看**147个玩家连入服务器的效果，与此同时服务器端还模拟着超过1500个活动的NPC**，它们需要每帧将移动信息复制给客户端。如果没有多核并行的加持，服务器肯定无法应付，但现在服务器的帧率居然能保持在**20帧以上**，成绩相当喜人。但是要指出的是服务器的出口流量已经上升至26 MBytesPerSecond，这个数据如果换算成Mbps还需要乘以8。也就是说必须采用千兆网卡才能满足上述的需求，因此数据的压缩和分帧摊销的手段不得不考虑进来，否则网卡将难堪重负。

![2b3b261a467de4087d001a5279df722e.png][]

虽然同时在线的玩家人数明显上了一个新台阶，但是离我们的目标依然有些遥远，是否单台物理机能够承载1000多个玩家暂时还不得而知，但并行化的框架给了我们很大的想象空间，随着核数不断的增多，我认为突破1000人的关口不会有太多的悬念。很快我司就要采购"AMD Ryzen Threadripper 3990X 64-Core, 128-Thread Unlocked Desktop Processor"这款CPU怪兽了，到时一切将会变得更加的有趣和刺激。

后续又进行了一次大规模的测试，结果如下：服务器端同时承载了1000多个玩家，平均帧率能够稳定在7帧以上。客户端的角色由于同步频率的关系，会出现一些拉扯的现象，但并不严重，大致还可以接受。64核的CPU被我们的应用消耗了40%左右的计算资源(还需要优化)。整体的带宽消耗了1Gb多(为此我们特意将内网升级到万兆的规模，全光纤连接)。

![64ae7e9589b5b324918adb3f4dd31e38.png][]

**- 点个****在看或分享****支持一下吧 -**

** 往期文章推荐**** **

[![2b202a667dbb68ee5ba283fa4beadc48.png][]][2b202a667dbb68ee5ba283fa4beadc48.png 1]

**游戏开发技术系列【想做游戏开发，我应该会点啥？】**

[![2351bed19332af40e98fbac4ca0b4ea7.png][]][2351bed19332af40e98fbac4ca0b4ea7.png 1]

**校招求职系列**

[![c63fca434406c4508de9ba24741fd6ae.png][]][c63fca434406c4508de9ba24741fd6ae.png 1]

**C++面试系列【史上最全的C++/游戏开发面试经验总结】**

我是Jerish，网易游戏工程师，5年从业经验。该公众号会定期输出技术干货和游戏科普的文章，关注我回复关键字可以获取游戏开发、操作系统、面试、C++、游戏设计等相关书籍和参考资料。

[Link 1]: https://mp.weixin.qq.com/s?__biz=MzkzNTIxMjMyNg%3D%3D&chksm=c2b3c34ef5c44a58ede7e1e37c52f1d9537567d61cd53d01c3e85818be6fca66fbde8728d99c&idx=1&lang=zh_CN&mid=2247493383&scene=21&sn=edcd7b0563f69e073af065c6d6d557bb&token=1308948739#wechat_redirect
[807e2756557c80e1b5f9b4843bfe7819.png]: /images/20220829/b476eac7dd5a4e03ac64e132c661c85e.png
[513f830f99442009f3a69a422ac8367e.png]: /images/20220829/3c28cf5b42cb491a83d2ccdf2c93e265.png
[15cd31e5a326ffc54705d0119d8c05bc.png]: https://img-blog.csdnimg.cn/img_convert/15cd31e5a326ffc54705d0119d8c05bc.png
[064bd6d92eb865ffda0d80c6b601b41f.png]: /images/20220829/4b46346fa2c74a259c0544c52b721fa6.png
[0bef8ff90bbdf9eba1b8cd399a07f9a8.png]: /images/20220829/413dbc4acb964d48b8a845baaa2720e1.png
[221314e56234da5b4b84d5dd7f42b705.png]: /images/20220829/3bc49a3cfcc340229c21960fd26bebcc.png
[8dd9691d14869c9e5153a745fa565860.png]: /images/20220829/1876d3acb50948a3b3d1d57ea0b3f770.png
[15e1337e4f7d6f91d1c47a8196c1c31e.png]: /images/20220829/f34ba723c3dc4e118723e3ffd0d0097e.png
[5a71db902132172eac7fe728aa522103.png]: /images/20220829/0415939a0981454499effb0230eb2456.png
[3f865a6a9ada84d305c275acd2074292.png]: /images/20220829/7417b4b029804dd8a729becc91298bbd.png
[feeaaf786e19bb71e66a929b22e6261a.png]: /images/20220829/74e24197b2e5418a80291c9de9272fe0.png
[285b0ebe32c87932d9582706b9c6af8c.png]: /images/20220829/7e12f68394b6478ea971163f31c2e871.png
[2b3b261a467de4087d001a5279df722e.png]: /images/20220829/4a38a5a7838048409306f502c8c626f7.png
[64ae7e9589b5b324918adb3f4dd31e38.png]: /images/20220829/ff813784e82341efaad76630257b8789.png
[2b202a667dbb68ee5ba283fa4beadc48.png]: /images/20220829/369a597b28a74366aadb7df5df5f2b5c.png
[2b202a667dbb68ee5ba283fa4beadc48.png 1]: https://mp.weixin.qq.com/mp/appmsgalbum?__biz=MzkzNTIxMjMyNg%3D%3D&action=getalbum&album_id=1742556256956923910#wechat_redirect
[2351bed19332af40e98fbac4ca0b4ea7.png]: /images/20220829/f5300a4a66e54265aa98b51425ba3e62.png
[2351bed19332af40e98fbac4ca0b4ea7.png 1]: https://mp.weixin.qq.com/mp/appmsgalbum?__biz=MzkzNTIxMjMyNg%3D%3D&action=getalbum&album_id=1742552130097332227#wechat_redirect
[c63fca434406c4508de9ba24741fd6ae.png]: /images/20220829/92c75e651c3c44e1a6d86ca0e4481931.png
[c63fca434406c4508de9ba24741fd6ae.png 1]: https://mp.weixin.qq.com/mp/appmsgalbum?__biz=MzkzNTIxMjMyNg%3D%3D&action=getalbum&album_id=1742549539124756481#wechat_redirect