问题背景

我的项目是对于开发一个看板类网站。上线后在应用过程中偶发性的报http申请超时。申请是应用axios，超时工夫设置为10s。

剖析过程

必须是后盾的锅
遇到超时问题，首先狐疑的就是后盾接口返回超时了。而刚好后盾也找到了差不多时间段的谬误日志，依据日志剖析又狐疑是hbase连贯超时问题。
通过后盾与大数据共事的一通操作，问题仍在，但出问题时谬误日志却没了。
前端上场
猜测无果，只能从前端开始正向剖析。

  1. 首先，剖析Http申请各个阶段的耗时状况。（用Fiddler和Chrome timing工具，实际上两者看不出太多区别。）

    从整个耗时来看，并没有超过10s。其中有异样的中央在于TCP/IP Connect耗时较长。
  2. 依据上一步的剖析，有两个狐疑点。第一个，TCP/IP Connect是不是因为域名解析耗时造成的，通过直连ip，并没有改善。第二个，前端同一时刻并发申请太多，申请排队，导致超时，通过限度并发数，问题仍在。
  3. 剖析无果，回过头来看一下axios超时原理。通过看源码，实际上就是应用的xhr的timeout属性，这是ajax规范语法。
  4. 此时有点狐疑是服务器配置问题。原理上来说，Http申请完结，开释TCP连贯后，服务器端TCP连贯仍将keep-alive 1-3分钟。如果短期内有过多的申请触发，可能存在连贯不够，重连超时问题。我通过不停的切换页面，频繁调用接口，在短时间内重现了此问题。此时终于找到了稳固重现形式。
  5. 依据上一节的剖析，咱们查看了服务器资源配置，服务器日志，都没有问题。同时在同一台电脑上，以后页面报错。立马重开一个tab页，从新关上此页面，却不报错。根本又排除是服务器问题。
  6. 突发灵感，看一下内存变动。发现页面内存达到250M，有异样。

  7. 通过剖析，的确内存在页面切换过程中不停增长，切被动回收后不能还原。
    内存剖析伎俩：应用Chrome Memory快照，依据字段名称局部能看进去是哪个元素。
    内存透露起因：

    1. Vue component办法被赋值给window变量，导致component不能回收
    2. axios cancelToken援用全局变量，导致所有的xhr实现后不能回收。此处有点奇怪，没有细剖析。
    3. echart须要在vue beforeDestroy阶段被动dispose，否则不能回收