这段时间主要是搞几件事情，一是性能优化工具，对于lua语言来说，网上现成的工具不多，之前项目测试过几次，主要还是使用lua自已的debug库，hook函数调用，然后对call记录开始时间，对return计算结束时间，这样就能算出此次函数调用花费多少和次数，这样算出来的时间并不准确，且并不能像火焰图那般，可视化一些关键路径和占比。然而对于一些请求其他服务的消息来说，内部使用协程来处理，这样，当请求时，消息进入另一个服务队列，然后挂起此协程，然后消息需要被工作线程调度，处理完毕后进入请求方的服务队列，最后唤醒该协程。然而什么时候被处理，一方面取于该服务队列的负载情况，二是被工作线程处理的时机，三是该消息真正被处理所花的时间。
在网上查找一些资料，有帮助的不多，像openresty，gperftool等并不能用于lua分析。后来使用有向图统计和debug相关的信息，计算每次函数调用时，判断有没有上一个函数栈，即父函数，作为子节点，然后把时间和次数累加到上面，就可以生成类似火焰图分析，当然这里也不能彻底解决协程的问题。
后来参考了下云风的博客，上面有介绍如何统计skynet负载的数据。他上面的大概思想是，对于call请求，先发一条trace消息到对应的服务，里面有本服务的地址和自增的session，和发送时间，然后在发真正的请求消息，这两条消息是连接到该服务的消息队列的。然后会设置收到该请求的时间，接着处理该消息，并记录处理时的时间点，然后发送响应。当收到响应后，该协程被唤醒，这样，有了这几个字段：sendtime/recvtime/resptime/signaltime，可以根据recvtime-sendtime算出队列负载情况，然后由resptime-recvtime算出处理时间，由signaltime-resptime算出本队列的负载情况，当然这里跟那博客中描述的有些出入，当然思想差不多。
二是优化下副本的组件要为下一款游戏使用，因为前两个项目中，写的一些副本玩法，要考虑的东西太多，比如倒计时要不要提示，进副本时有遗漏处理，离开副本时有四五处要处理，写过多的重复代码和可能的出错，之前重构过相关的实现，但不彻底。还有些影响性能的实现，上一款上线的游戏，性能不够优，每个32GB的内存16核的，如果全部单人打pvp副本，顶多四千多个同时进行最耗时的玩法，剩下的其他人游戏会明显卡顿，这块持续重构中。
后面慢慢分析bfs。
网友评论