由于上上周尝试做了运营活动，关键代码大概三四百行的样子，其他复用代码大概三百行。之前这块是有其他同事统一负责的，然后策划那边提需求时，那位同事不在我就接了这个事情。虽然很简单很简单，但是通过这个过程我有几点体会。我是花了一点时间看了那边整个实现“框架”，活动的开启，关闭，在线更新，后台推数据，刷新等都是已有的，增加一个活动的时候只需要写关键的部分，这样就减少其他潜在的错误，但是如果这块没有测试充分那么全都有影响。那边活动开启会回调注册的函数，包括更新活动会走更新，由于某些版本会通过后台post数据到某个service服务更新数据，这块要各自写检查函数，就是保证到内部逻辑那边，数据格式和内容都是要满足各业务需求。
然后我写的时候，因为有一部分代码和之前的一样，就拷贝了这一部分。但是没有具体考虑到业务场景，使的一开始实现不那么友善，后来在提交的时候review自己的代码发现这儿不对劲。我这边需求需要频繁调用，不能阻塞关键流程，而原来逻辑低频次且有两个call，为什么要call呢，因为在操作一次时要同步检查数据的有效性，此时阻塞，而这部分完全可以缓存一定时间并淘汰，这样就非常完美了，我这边可以放行第一次call请求走异步请求数据，直接返回临时不可用的数据是可行的，等数据回来后缓存，后期直接命中在有效期内的数据，不再阻塞。那会也测试过后台post更新数据是否正确的情况，没有测试充分导致更新出去时出现问题，发现框架那边的老bug，条件判断出现错误导致把正确的数据给覆盖掉，而且格式也不对。
但为什么现在才触发？还是测试路径没有覆盖到，和测试用例不充分。但因为这个老bug，导致其他活动更新出现问题，因为框架那边是个for循环，某一步出现错误报堆栈错误，剩下的逻辑不跑了。通过这么个经历，意识到四个方面，一是复用其他代码，一定要了解这块代码的业务场景和自己要实现的需求；如果复用的代码比较复杂，还是要多分析下并且简化；二是代码的每个if条件判断，考虑失效的情况和引起的问题，是否是隔离的还是关联性的，不能因为一个次要的更新导致关键路径出现失误；三是阅读基础代码，哪怕感觉很简单的实现，还是要多分析下，是否设计合理，该检查的都检查，不是说你一直做复杂的模块或者职位是高级资深，让你负责某个小模块就是大材小用，不是的；我一直都会review其他同学负责的模块然后思考有没有问题以及是否存在其他更好的方法。因为某些时候在赶需求可能目前的实现虽然对，但性能方面没有考虑到导致后面的影响范围进一步扩大（这边早期项目代码性能方面坑很多，同样配置，早之前压测同时在线约两千人，到后来的五六千人同时在线），很多功能仅仅是实现但并没有考虑到更合理的方案并经过实际测试对比。毕竟总体目标是一致的，把项目做更好。
这几天一直在服务器上跑机器人测试，修改代码前后的性能数据对比，修改后的定时器总代码行130行左右，并且接口都没有变，实现不一样，还没有提交。由于自己本地工作环境是虚拟机，一次性上两百个机器人进单人副本就卡的不行，所以测试时用的是服务器测试机。服务器是业务进程，本地虚拟机是加一批机器人，跳到跨服战斗。
测试机器的配置是四核的，3.2GHZ，再然后因为测试时开的八个工作线程，包括主线程一共十二个，那么必然会发生线程的上下文切换。此处的统计另外再说，一般线上机器核数会和线程数比较接近。
我修改了底层框架，加上一些统计的代码，每秒打印添加定时器的次数，唤醒次数，未唤醒次数，不影响测试数据。
这里列一下修改前的数据说明，一共两次规模测试，每次三轮。虽然该机器性能也不大行，一次上两百个机器人进入5V5的PVE，因为走的是新手引导副本，比较简单，战斗应该不会很激烈，该副本其他九个人是“机器人”，算是一个由AI驱动的对象，然后有一只怪，这样一共创建200个副本，一个主场景，每几个副本对象占用一个虚拟机且负载均衡，每个副本中有11个对象，此时测出的数据是，每秒添加定时器消息2.4万次左右，并且唤醒2.4万次左右，还有一些未超时的，此时该进程cpu总用户时间160左右，内核时间7左右；测试三轮数据很接近。副本持续时间一分钟。这里实现一个定时功能需要4.8万+条消息。cpu采集数据每两秒一次。
第二次是五百个机器人，即500个副本，两个主场景，每个副本11个对象。每秒添加定时器消息在4.6-5.2w，唤醒4.5w+，持续观察采集数据，比较接近。观察cpu用户时间280，内核时间15，比较稳定，副本持续时间一分钟很快结束。
之后，五百个机器人回到主场景，站着不动，此时每秒添加定时器消息700-1000次不等，定时器超时消息数也很接近。cpu用户时间5左右，内核时间1左右。
以上测试都是没有野怪的主场景，如果是野外场景，那么就有很多定时触发的野怪AI。而且以上测试都是副本战斗，其实更准确的测试应该持续性的激烈战斗，需要观察cpu和网络相关信息。另外没有出现消息队列overload负载高的情况，正常游戏开服同时几千人进副本的情况基本很少出现，可以在业务层对某些不那么重要的但比较影响性能的系统做降级处理，保证在游戏中的玩家正常游戏，和关键业务逻辑不出现问题。
修改后的测试，步骤和上面一样。统计出的数据分别是，200人的情况：cpu用户时间135左右，内核时间5，每秒底层定时器统计800多条；500人的情况：cpu时间240和内核时间9，每秒添加定时器1400多条。定时器管理每50ms触发一次，精度应该可以，如果要再细则可以调整。这样每个虚拟机每秒20次注册到框架层。以上优化后的效果体现主要是在战斗情况下才明显，如果所有玩家只是简单跑跑任务什么的不发生战斗，和原来相比，提升不那么明显。另外修改前后的数据测试并非完全一样，因为跑到的逻辑会不同但多次测试数据相近，应该有可信度。如果同时在线六千人，基本是在最高上限往下调一定比例的，一方面不大出现几千人同时进副本。每个虚拟机还有其他低频次的定时器也统计在内，占每秒比重几乎为零。
之前在那种去跨服的25V25的PVP玩法中，集中某一时间，有近1000人参与，还不包括其他去跨服活动的情况，印象中当时总cpu占比低于50%，主要是进行了几次优化相关的实现。
优化的主要目的是减少线程间的竞争以及加解锁，降低频率。减少上层往消息队列中投很多消息，内存方面的操作，以及不必要的线程调度，让cpu做更重要的事情。因为消息队列里的消息，来自于客户端的主动请求，定时器的超时推送，内部服务的推送，后两者更能影响系统的性能问题，保证消息队列中消息生产速度远小于消费速度。另外该框架底层实现也有几处可以优化和扩展的地方，当然还是要看出于什么业务需求，不能过早优化，有时候复杂的业务实现差反过来也会影响框架的性能，降低应用后期的可维护性，反正多思考些。
2020.1.4号更新，修复定时器偶现怪不动的bug，减少hash操作，测试数据稳定，测试一百人的时候，老实现cpu占比~90，新实现的占比~70，每秒定时消息从2.2w+(一来一回)减少到1200+(一来一回)，另外由于测试200和500人时，机器人进程和业务进程在同一台测试机上，可能会有点影响。整个新的实现比老的cpu消耗降低约15%~22%，其他内存相关的未关注，后期补上。虽然提升了一些，但还是比较耗性能，战斗这块涉及逻辑较多和复杂，还是有很大的优化空间。
——广州
网友评论