最近一段时间在做优化，继续关注线上bug，额外是安全，压测和容灾相关的工作。
先总结下这段时间发现的问题，主要是稳定性和体验，比较经典。其他同事加了一些功能，但在几次测试的时候偶现玩家登陆卡住几秒，后来再登陆就没有出现这样的情况。再后来加的一个功能导致登陆必定会卡几秒钟，后来问了该同事是配置问题，加上配置后就会跳过。但是这里并不是配置的根本原因，因为在登陆的时候会同步走网络请求数据，那这块是有问题的，请求次要数据可以走异步，让登陆尽快完成，带数据回来后再设置，因为网络的不稳定的，这样修改后就不会再卡，至少不是必现。
本以为找到卡的原因，后来又偶现，还是在登陆时。翻了之前的聊天记录，查看相关代码在登陆时并没有同步请求，后来发现第一次登陆可能卡可能不，后来登陆的玩家就不会。在日志那边打印log跟踪，发现在登陆时需要给这个服务发送异步消息，但是该服务并没有在程序启动的时候创建，所以创建一个虚拟机，虽然创建本身耗时，创建初始化的时候，去走网络请求一些数据，那么就会卡住。第一次会创建，因为是唯一服务，后面就不会卡住。把这块放到启动的时候创建并请求会更合适。
还有一个问题同事那边比较难解决，后来一起排查。从网页操作数据，比如给玩家发送元宝，那么到php这边后，php封装请求到游戏进程，然后处理。出现的问题时，有时候成功有时候返回失败。后来排除数据格式问题，排除逻辑问题，排除进程负载高的情况。查看网络链接，发现返回失败后处于timewait，这个没问题。然后跟踪到比较久远的底层代码，有个定时器，设置超时时间是一秒，把这个设置长一些就解决了。
包括还有些设计方案不大合理，平滑处理会更好些。
之前想聊聊游戏系统中聊天模块和邮件模块实现的要点，系统功能的设计其实不难，关键在于细节，设计细节，包括稳定性，性能，存储等这些。如果没有相关经验，设计之初可以不考虑性能和流量消耗，后期可以根据业务需求去优化，这样经过几轮迭代后面不管压测还是安全测试独立没什么问题。
之前压力测试时，聊天系统出现一些问题。这块代码和设计是沿用上一款游戏的模块，不是我写的。虽然后期优化什么的把这个实现梳理了遍并做了些调整。机器配置就不说了，压测报告出来时，四千机器人同时在线，一千个人同时发世界广播消息，出现了cpu负载很高，且延长较大，持续了几秒。算了下，一秒发送400万消息，不考虑内容大小和处理逻辑，仅仅转发，都够呛的。之前博客记录过一些相关的优化点，这里还可以再激进些优化。由于skynet框架的特点，如果优化skynet框架其实没有必要，只能去优化用户代码。
仔细分析这块逻辑的消息走向，然后列出瓶颈，一个个攻破，由于是多线程，不能因为一个非重要的聊天系统拖累整个系统和用户体验，这里再次优化下。
一般客户端只能显示一定数目的消息，一下子发几千条大部分没有必要，大部分都超时，可以做适当的丢弃，这块还是可以优化下。
以上，可以优化的地方很多，总之是稳定，不卡顿，节省资源和带宽。这样设计后，模块清晰，解藕、后面可以针对性优化和替换。
网友评论