某天，不知道是谁最先发现的，在浏览器端不停的刷新一个列表请求，然后响应会越来越慢，响应时间越来越长，领导知道了就过来询问，spring处理一个请求是不是并发的呀？不停的刷新，为什么响应会越来越慢呢？
昨天，某大牛出手了(嗯，就是前几天说的刚转到团队的)，真相终于大白，在浏览器端不停的刷新，浏览器会把请求阻塞的，上一个请求响应完成，下一个请求才会向后端提交，如果短时间内连续不停的点击"刷新"按钮，阻塞队列就会越来越长，那么后续的请求也就是你看到的"越来越慢"。
实际上从冯诺依曼架构，程序局部性理论来说，每一次的处理应该越来越快才对，你所看到的"越来越慢"只不过是浏览器的阻塞时间变得越来越长，请求的真正处理时间会差不多，理论应该更短。
都是做后端的，谁这么牛叉，最早发现的？
经验很重要。
很多时候，问题的解决方案不在问题的所在层，而往往在相邻层面。
如果一开始按照怀疑spring的思路出发，接下来就会加日志打点统计处理时间，最后会得出不是后端的问题，这个时候才开始怀疑浏览器端，很多时间都"浪费"了。。。
更牛叉的是解决问题的人，没有在后端日志打点，一出手就发现是浏览器端的猫腻——浏览器会对同一个域名的请求进行阻塞，如果在浏览器上不停的点击刷新，上一个请求得到响应，才会处理下一个请求，点击越频繁，阻塞时间就越长。
因为我们的工位都离得不远，当大牛跟领导解释清楚之后，领导深深地长长的叹了一口气——"哎。。"，这是以前从来没有听到过的叹气，我真真的能听出来，这一生长叹里面有好几个意思。
网友评论