时间过的真快，回头看了下今年给自己安排的事情还是挺多的。过去一段时间有点迷茫，一方面感受到寒冬，同行那边有裁员发生，论坛上有类似的贴子，只是没发现身边有这样的情况。年后的一个月，发现有些同事离开了，才知道是裁员了，给的n+1补偿，公司和这边做的也算不错了。当然自己感觉挺难过的，希望他们都有个更好的去处吧。去年的项目并不好，虽然过程中收获一些，又在重新否定自己，是否做到位？开始了新的项目，自身又能突破哪些，解决什么问题和不错的方案，给团队提供多少价值？
上两周主要是写性能分析工具，之前的文章中也描述相关的情况。当时是用lua写的一部分，本身统计也不准确，然后无法统计到协程的处理时间及消息的准确耗时，后来重新用c/c++实现相关的功能。
当时写这个时，网上没有多少参考资料，只能结合平时的lua debug api去看lua的部分源码，然后根据需求去实现相关的功能，当然这里踩了一些坑和一些初步方案的不可行性，写了一些没用的代码，花了一些时间去验证这个行不行，那个怎么样。
现在能实现了统计每条请求消息或者内部消息的准确处理时间，次数，和消息在队列中等待的时间，当前接收到多少，处理到多少，能知道负载情况和消息队列中充满了哪些类型的消息。
因为skynet框架并没有提供处理负载的功能，只是一味的接收消息，可能导致占用内存过多，消息处理不过来，做无用的功能，导致响应慢。而monitor线程定时检查到某个服务的消息队列消息过多时才会给个提示，其他的不会再做什么。
也能统计一个lua虚拟机的所有函数调用开销，包括关系，时间，次数等信息，或者指定消息的开销数据。这里也踩了一些坑，后来去看lua创建协程的源码，也想过通过api取某一桢函数的参数等，这样太复杂了，后来想到个不错的简单方案给搞定了。因为要考虑的点比较多，比如不让本身的统计占性能，不做过多的事情，且能正确。
因为没有好的工具去可视化统计出的数据，类似火焰图那种，也没具体研究过openresty中的怎么弄的，就简单的做了下有向图的遍历，也出现了有环图导致无穷递归最后core dump的情况，因为在函数调用时，出现了有环的情况，这里也要小心处理。后面如果还有时间，想把统计出的数据按照能使用可视化工具的要求，把输入数据整好导出直观的统计，方便查看热点。
当时主动接这个需求时，以为不难弄，一开始在lua中弄的，发现不行，搞不定，后面硬着头皮在底层实现，当时也并不熟悉lua源码(现在也不熟悉)，觉得不大可能实现。可是，如果在时间允许的情况下，还是要多思考，多想办法，从源码入手。
之前分析的bfs停下来了，主要前几周没啥时间，周六也上班，后面继续分析它。
最后，不管是不是在寒冬，都要去学习和提升。
网友评论