背刺来袭
“S市的小伙伴们普遍反应测验渠道贼不好用，都快要抛弃重整旗鼓了！” S市的事务测验负责人给上了重重的一记背刺。小树懵在原地，脑袋都是嗡嗡的，脸上也烧了起来。比较之前的反应，这次生猛了许多。当然沉着的小树这时分会开端沉思了，到底是哪里做的不好。背面的问题其间一项是有一个接口恳求超越13秒，并且这个接口在运用的主流程中还特别频繁。那这个问题究竟是怎样来的呢，那我们就得从小树刚进入公司H市分部开端说了…
背刺的由来
小树一进入公司，就迅速的搭起了一个基于metersphere的开源测验渠道。也顺利推广了开来，开端安然无事，最多便是会有些不知道组件怎样运用的问题，平平安安的度过了3个月。3个月后，小树也正常开端展开做其他相关的渠道保护和开发作业，期间偶尔会有些声音抱怨渠道有的时分会比较慢，也不知道是恶作剧仍是真有问题，一般我们都是笑笑就过了。小树承认往后，没能重现也就不了了之了。
时刻转瞬又过了2个月，S市的小伙伴反映卡顿的频次逐渐升高，这不由让男主置疑起来是否有什么问题，所以和H市的同事了解状况，可H市的同学表示快的确不能说是快，但也还能承受。随后S市断断续续的再反应着，但是也不是特别急切，所以又带着问题过了2月，从渠道初建到现在，小树发现，2地的同事的自动化脚本水平越来越好，从最初的写个单接口写个校验，到最近的模块化，规模化改变都是非常惊人的。脚本的数量级和脚本的杂乱程度也不可同日而语。特别是S市的脚本有着翻天覆地的改变，单个脚本的能力都是多样且强大。
话说回来，就在这个时分，H市也连续有同学开端反应该接口的呼应体感上的不能承受。这个时分小树才正式介入，定位接口，然后经过前端缓存接口内容，减少调用次数，从而减缓推迟带来的体感不适。原以为故事到这儿就完毕，又康复天下太平了。
事与愿违，就在又过去2个月后的今日，小树懵在了原地，问题并没有处理，并且S市同学现已不想再忍了，最终捅到了主管那里。其实小树并不会由于主管的压力感到伤感，仅仅会对反应感到内疚不安。所以就又开端了从头和问题斗智斗勇。
提刀上马
经过了之前一次调优的经历，小树很快便找到了问题接口的代码，又从头读了一遍，这次明显比之前更快。这儿的循环做的恐怕有功能问题，递归加数据库（io）查询，想不慢也难，小树灵机一动，心想：这个渠道是个开源渠道，想必其他人也有这个问题，很可能现已被开源安排优化了吧。抱着试一试的心态，小树提刀上马找起了开源代码上是否有更新记录。功夫不负有心人，问题块的代码的确被优化过了。
同步了最新代码，本地起了服务并敞开了调用链路盯梢监控恳求的时刻开支。
不难看出，整个接口恳求时刻开支只用不到240毫秒，这可比线上的13秒快了不知道多少倍。所以开开心心的结案了，坐等应用发布。问题应该就此处理了，小树开开心心的去做其他作业了。
不出意外，就要出意外了
总算到了发布窗口，发布完后，小树直接找来几个S市同学写的自动化脚本，直接尝试了下这个慢接口对应的功能。功能有提高却不大，从本来的13秒左右降低到了10秒左右。全体功能体会上仍是不能承受，太糟糕了。小树感觉到非常无力，苍茫。心说：怎样可能呢，分明我本地秒级的东西到了线上要十秒级。数据库本地连接比服务器连接更慢，要说有改变也应该是服务器上更快才对。
所以用arthas在云服务器上也追踪了下办法的调用时长。全体数据表现和本地表现差不多，甚至的确更快一点。只要130毫秒左右。
小树不解之余，一次次的trace ，折腾了好一阵子，最终发现即使是整个接口办法也只需要不到200毫秒。整个arthas的排查过程花了不到非常钟，却让小树如度春秋，更是落井下石，更加没有头绪没有规矩。
再战
小树原先盯着Chrome浏览器的开发者模式窗口接口时长上写的9.3秒的眼睛，也渐渐的失去了光泽。 突然间眼里泛起了微光。这儿有点点古怪啊，小树心里萌生了一些东西。由于小树的鼠标焦点移到了瀑布图上的时分，小树发现：
这儿有一个点很古怪，为什么恳求的发送时刻比恳求处理时刻还长这么多？ 这个是怎样回事。所以小树查看了下恳求数据。瞬间被吓到了，一个恳求体居然有6.3MB，这个接口回来只有不到250B，完全是2个数量级。
小树经过前后端gzip加压解压的方式进行了优化，由客户端和服务端进行数据的展开，减少网络上的耗费，顺便在紧迫发布窗口从头发布了测验渠道。
// 前端压缩恳求体，公共办法
export function zipString(content) {
return btoa(pako.gzip(content, {to: 'string'}));
}
// 后端解压恳求体，公共办法
public static String ungzip(String content) {
byte[] bytes = Base64.getDecoder().decode(content);
try (ByteArrayOutputStream out = new ByteArrayOutputStream();) {
IOUtils.copy(new GZIPInputStream(new ByteArrayInputStream(bytes)), out);
return out.toString();
} catch (IOException e) {
throw new RuntimeException(e);
}
}
恳求全体时刻从原先的13秒直接压缩到秒级。发布今后问题总算得到了处理，小树心中的大石头总算放下了。等待第二天的到来，好找S市的同学求证最终作用。
小树的总结
为什么这些问题之前没有发生，小树最终整理了下信息，其实自动化渠道现已逐渐深入人心，同学们的思路也渐渐被翻开，运用的方式办法也会越来深入，所以恳求内容也就越来越大，小脚本的状况下，这个恳求内容也不会有这么大。只能说小树的新目标又有了，为了适配小树的公司环境，小树需要做更多的改造让测验渠道能适配发展中的公司了。
有了这次的经历，小树对待技术，又多了一些感悟，在这次问题的处理中，其实问题相对仍是比较简单，很快便被定位和处理了。看问题仍是得要从头到尾琢磨一下，由于无论是开发的东西也好，办法也罢，都是一点点积累起来的，难保某一个小分支小细节不会犯错，所以看待问题的时分仍是得有大局视界，去找寻这些问题和方向。
随后小树便开开心心的在晚上12点的钟声敲响前5分钟，关掉了电脑，钻进了被窝.不久就进入了梦乡。
…然后…在某个阴暗的角落，有一个bug正在静静地注视着小树…
欢迎重视微信公众号：树叶小记，发现更多精彩
