问题

生产环境上，有客户反应某个页面，点击时非常慢

然后，有个测试同事，这个测试的账号给我登录，然后亲自重现排查下原因。发现，该页面，第一次加载入去时，点击[对话]的响应时间还可以接受。但是过了几十秒之后，再点击就变得非常之慢了（有时整个请求耗时差不多1分钟….，这种情况，只有再现大量数据时，才会呈现这种问题）

排查

一开始，我以为是点击时请求[对话]某URL的原因，然后线上hot fix加入方法调用时间的统计，发现非常慢的时候，前端还一直在等待，但服务器却没有打印出我的加入时间统计的日志，等完成时，却发现一个非常奇怪的现象：

前端显示该请求的 responseTime 为 51s

但后端统计调用该方法直到返回，整个处理耗时为100ms

为何会差别如此之大？

实在不得已，然后请了前端的同事，过来帮忙看看原因。然后同事再次打开浏览器调试工具，发现非常慢的那段时间，有不少其他的请求一直是等待状态，服务器响应未完成。

这…….

经前端同事的指出，才知道Google Chrome浏览器，同一个tab对同一域名的最大同时连接数是有限制的.可以通过如下方式查看:

在浏览器地址栏输入以下:

chrome://net-internals/#sockets

解决

经过这次排查，发现自己一开始时的排查方向都是错的。因为问题的根源，并不是点击[对话]的URL的后端处理导致的。而是由于其他的URL，导致服务器没有能及时响应，而这些又是前端轮询的。所以，当服务器出现不能及时响应时，就会造成不少同时连接到同一域名，从而达到浏览器的连接上限，其他的请求，就只有挂起了。所以，才看到整个处理时间，前端与后端差别这么大。

找到根源的那个URL请求，然后优化了下该代码就好了。

总结知识点

  • 浏览器对同一域名，最大同时连接数是有限制的

  • 前端的http请求，没有添加 timeout

  • 这次慢的原因，是因为后端代码的redis遍历问题，而且还是（1）获取某个zset的memebers –> （2）获取每个memebers的对象（当时是有2W多个Key），这在以后用redis要特别注意.