共计 942 个字符，预计需要花费 3 分钟才能阅读完成。
问题背景
我的项目是对于开发一个看板类网站。上线后在应用过程中偶发性的报 http 申请超时。申请是应用 axios，超时工夫设置为 10s。
剖析过程
必须是后盾的锅
遇到超时问题，首先狐疑的就是后盾接口返回超时了。而刚好后盾也找到了差不多时间段的谬误日志，依据日志剖析又狐疑是 hbase 连贯超时问题。
通过后盾与大数据共事的一通操作，问题仍在，但出问题时谬误日志却没了。
前端上场
猜测无果，只能从前端开始正向剖析。
- 首先，剖析 Http 申请各个阶段的耗时状况。（用 Fiddler 和 Chrome timing 工具，实际上两者看不出太多区别。）
从整个耗时来看，并没有超过 10s。其中有异样的中央在于 TCP/IP Connect 耗时较长。 - 依据上一步的剖析，有两个狐疑点。第一个，TCP/IP Connect 是不是因为域名解析耗时造成的，通过直连 ip，并没有改善。第二个，前端同一时刻并发申请太多，申请排队，导致超时，通过限度并发数，问题仍在。
- 剖析无果，回过头来看一下 axios 超时原理。通过看源码，实际上就是应用的 xhr 的 timeout 属性，这是 ajax 规范语法。
- 此时有点狐疑是服务器配置问题。原理上来说，Http 申请完结，开释 TCP 连贯后，服务器端 TCP 连贯仍将 keep-alive 1- 3 分钟。如果短期内有过多的申请触发，可能存在连贯不够，重连超时问题。我通过不停的切换页面，频繁调用接口，在短时间内重现了此问题。此时终于找到了稳固重现形式。
- 依据上一节的剖析，咱们查看了服务器资源配置，服务器日志，都没有问题。同时在同一台电脑上，以后页面报错。立马重开一个 tab 页，从新关上此页面，却不报错。根本又排除是服务器问题。
- 突发灵感，看一下内存变动。发现页面内存达到 250M，有异样。
通过剖析，的确内存在页面切换过程中不停增长，切被动回收后不能还原。
内存剖析伎俩：应用 Chrome Memory 快照，依据字段名称局部能看进去是哪个元素。
内存透露起因：- Vue component 办法被赋值给 window 变量，导致 component 不能回收
- axios cancelToken 援用全局变量，导致所有的 xhr 实现后不能回收。此处有点奇怪，没有细剖析。
- echart 须要在 vue beforeDestroy 阶段被动 dispose，否则不能回收
正文完
