九月份接到一则需求有关广告业务的gap报表需求（gap这里可以理解为公司内部广告曝光/点击监控数据和第三方广告曝光/点击监控数据的差值与公司监控曝光/点击数据的比值）。
产品文档涉及数据较多，均出自不同的数据表，查询数据是来自调用rpc服务获取的基础数据，表报接口拼装统一数据对象对外展示。服务主要分为三个维度查询，按天查询，按小时查询，按地域查询，由于按小时和按地域查询查询条件都是拿到具体的广告ID查询广告拼装每条广告在不同时间范围内（一天24小时）或在不同地域（大概33个省）的数据计算展示，数据量有限查询均为700ms左右，速率还可以。但是在按日期查询广告数据时，按时间范围，默认查询当天的在投的并且匹配到监控公司的广告数据大概有20-30条左右，数据显示量也不大，但是查询耗时达到4秒左右，开始以为是因为我使用内存分页的原因，但是加日志排查耗时，内存分页在现有的数据量下耗时基本为0，主要耗时的位置在业务逻辑for循环去封装数据的buildAdGapBO方法上，很纳闷为什么为在这个方法上，几经周折，提取出来内部调用通过外部批量查询的数据列表生成map数据，buildAdGapBO中通过map获取对相应的依赖对象进行数据封装，优化上线后，效率有所提升，但每天的数据基本保持在4秒左右查询，（翻看了一下其他页面查询代码，数据量都不小，但查询在1秒一下，疑惑，为什么其他的查询能在一秒一下查询出来？难道是因为内存分页？可是这个查询耗时打印内存分页并不耗时呀，难道是因为数据来源是通过rpc的调用？还是因为查询的条件没有索引？按条件一个表一个表的排查，都有索引啊，并且条件是可以走索引的。。。）
思前想后，百思不得其解，晚上回家的路上想到H神，对向H神求解，于是向H神提问，把我的问题和H神讲了一边，H神回复用Arthas排查调用耗时。我问线上的也可以吗？可以的，不要猜，用Arthas 可以很清楚的查出服务调用耗时问题。我回复好的，明天回去就试一下。
第二天一早来到办公室，立马查找Arthas的使用文档，因为我司用的是mac安装方式也挺方便。起初担心自己的操作会对公司服务造成影响先向同事老师说明情况，因为老师没有用过线上排查耗时的问题，所以提示可以先在联调环境下排查，并告诉我了安装方法。
1.搭建联调环境
2.登录到联调环境
3.在联调服务器上安装Arthas因为我司用的是mac所以我的安装命令使用的是
curl -L .sh | sh显示Arthas install successed.表明安装成功
3.直接在shell下./as.sh就进入了交互页面
命令输入后，调用接口查询，就会有接口的查询详情打印在下方，注意要多调用几次，只看一次的查询结果可能会出现某个接口查询突发性的时间过长，误导排查结果。
查询结果大致如下：（上边为单个接口的耗时，下边为for循环接口的耗时，均为平均耗时）
找出耗时点，发现耗时问题在我每天查询的结果是在投广告的指定几十条，但是在投广告的过滤在buildAdGapBO方法之后，也就是调用buildAdGapBO封装数据的广告会远远大于指定的广告数量，所以优化方法就很快得出，就是在调用buildAdGapBO之前提前把广告过滤了。减少不必要的buildAdGapBO调用，以此来优化。
果不其然，过滤后速率从原来的4秒提升至1.7秒左右。
期间遇到的问题点：
1.在trace时遇到No class or method is affected,
2.根据提示sm 发现方法是加载成功的
3.使用cat /root/logs/arthas/arthas.log 命令得到如下的日志 Method too large 的error信息
这里说的是我的方法过大，确实是超过了300行，解决方法是把这个方法提取让这个方法尽量的小。
下边附上我的参考文档：（还有很多技术博客，就不一一列举了）
.html
最后再次对H神表示感谢，一点点进步就可以满足一整天的成就感，无比的开心
本文发布于:2024-02-01 02:33:17，感谢您对本站的认可！
本文链接：https://www.4u4v.net/it/170672599933232.html
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系，我们将在24小时内删除。
| 留言与评论（共有 0 条评论） |
