昨天系统发了一个版，结果发上去后发现了严重的性能问题，排查的过程还是挺有意思的，记录一下。

症状

页面上有一个tab空间，每个tab里有一个data table。用户切换tab的时候，会去服务端请求数据做展示。

发版后，我照例去点击一下，看看效果。结果让人吃惊，切换tab后，20多秒后页面才加载完成。

怎么回事？开始排查。

API性能崩了

第一时间就去查后端服务。

当然，公司后端服务的监控已经很健全了，不到一分钟就确认了，后端服务是OK的，不到1s请求就完成了。

那问题一定是在前端了。

Stalled 时间过长

浏览器debug窗口打开，找到了那个非常慢的请求，在Timing窗口中看到了，Stalled占据了99%的时间。

Stalled既然被划分在了Connection里，那说明建立连接受阻。关键切换tab的时候就只发出去了一个请求呀，也没有并发太多，为什么无法建立连接？

前端同学看了一眼说，肯定是界面上DOM元素太多，浏览器是单线程的，一定是在渲染DOM的时候，阻碍了TCP的连接。

这个时候已经比较晚，负责这个模块的同学已经下班。所以回家。

破案了

今天上班后，由于早上基本是开会的时间，就把这个事情安排给了前端同学。

在开了三个无聊的会后，前端同学已经对代码做了不少优化，前后发了三个版本。可是，对性能的提升几乎没有。

不得不说：元芳，看来这里的水很深啊。

看来需要换思路了，还是得从网络方面下手。

网络排查，首先想到的是wireshark，很可惜，没有管理员权限。在申请管理员权限的同时，我在想，难道浏览器没有更好的网络排查工具吗？

结果还真被我找到了，就是NetLog Dump。

启用 NetLog 的方法很简单，在网址栏输入 edge://net-export/ 或 chrome://net-export/

后面就是开始和结束记录即可。

要查看 Log 内容，可开启 https://netlog-viewer.appspot.com/#events 网页，导入json文件（文件只会在浏览器端处理，不会上传到网站）。

结果打开我自己记录的Log文件，找到对应的event，就立即破案了。

就是连接池满了，因为浏览器都会限制对同一个主机名的站点的连接数。

另外，还发现了大量并发的对同一个站点的请求的event。这个时候把前端同学喊过来问，不是切tab只有一个请求吗？其他请求哪来的？结果他才想起来，是一个记录日志的程序，使用的sharedworker，所以在debug窗口里看不到。

既然找到了原因，修改也就很容易了。

小结

这个case其实也不是很复杂，只是最近业务项目做太多，已经很少解决这种类型的case了，于是记录一个。