源起
最近在工作中遇到了一个前端发送http请求,但在chrome浏览器上经常出现状态为request cancel的问题,通过深入分析这个问题填上了之前同事埋下的openresty阻塞的一个大坑。
问题定位分析chrome产生request cancel的原因
通过chrome的net-internals的events,发现chrome产生cancel的原因是因为在发出请求后2s后没有收到response,所以cancel了。
进一步分析前端代码,发现前端的ajax的请求的timeout设置的是2s,但到底是http请求没有发到服务端,还是服务端收到请求但是没有响应呢?抓包定位问题产生在服务端
在服务端用tcpdump抓取http的报文,确定http请求服务端收到了,只是没有在规定时间内返回。
前端timeout的机制后续会继续retry,但是出现大量的request cancel,看起来像是服务端由于某些原因被阻塞了。通过日志定位问题产生在磁盘io的阶段????
通过服务端打印的日志发现服务端在文件上传阶段一直在打印写磁盘的日志,等文件全部上传结束之后才会响应其他请求。
由于nginx worker采用的是单线程事件机制来处理并发,看起来像是磁盘io操作阻塞了nginx的事件机制导致了不能响应前端的http请求。
上面的解释似乎很有道理,但是事情的真相真的是这样吗?
继续深挖一切都只是怀疑,需要多方验证
但是还有一个问题:
测试环境是百兆带宽的局域网环境