网站建设中的问题,wordpress 制作专题,自助建站官网,wordpress怎么设置主题在这篇博文中#xff0c;我们抛开对阿里云的怀疑#xff0c;完全从ASP.NET的角度进行分析#xff0c;看能不能找到针对问题现象的更合理的解释。 “黑色30秒”问题现象的主要特征是#xff1a;排队的请求#xff08;Requests Queued#xff09;突增#xff0c;到达HTTP.…在这篇博文中我们抛开对阿里云的怀疑完全从ASP.NET的角度进行分析看能不能找到针对问题现象的更合理的解释。 “黑色30秒”问题现象的主要特征是排队的请求Requests Queued突增到达HTTP.SYS的请求数Arrival Rate下降QPSRequests/Sec下降CPU消耗下降Current Connections上升。 昨天晚上18:08左右发生了1次“黑色30秒”正好借此案例分析一下。 1、为什么Requests Queued会突增 最直接的原因是ASP.NET没有可用的线程处理当前请求。为什么会没有可用的线程呢ASP.NET可用的线程毕竟是有限的可能是当时瞬间的并发请求太多ASP.NET来不及创建足够的线程处理这些请求。 我们来看一下ASP.NET中线程相关的设置——machine.config中的processModel位于C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config。 有4个相关设置maxWorkerThreads默认值是20, maxIoThreads默认值是20, minWorkerThreads默认值是1, minIoThreads默认值是1。这些设置是针对每个CPU核 我们用的就是默认设置由于我们的Web服务器是8核的于是实际的maxWorkerThreads是160实际的maxIoThreads是160实际的minWorkerThreads是8实际的minIoThreads是8。 基于这样的设置是不是如果瞬间并发请求是169就会出现排队不是的ASP.NET没这么傻因为CLR 1秒只能创建2个线程等线程用完时才创建黄花菜都凉了。我们猜测ASP.NET只是根据这个设置去预测线程池中的可用线程是不是紧张是不是需要创建新的线程以及创建多少线程。 那什么情况下会出现“黑色30秒”期间那样的大量请求排队假如并发请求数平时是300突然某个瞬间并发请求数是600超出了ASP.NET预估的所需的可用线程数于是那些拿不到线程的请求只能排队等待正在执行的请求释放线程以及CLR创建新的线程。随着时间的推移释放出来的线程新创建的线程足以处理这些排队的请求就恢复了正常。 那如何验证这个猜测呢 修改maxWorkerThreads, maxIoThreads, minWorkerThreads, minIoThreads的设置让ASP.NET提供更多的可用线程目前我们采用的设置如下 processModel enabletrue requestQueueLimit5000 maxWorkerThreads100 maxIoThreads100 minWorkerThreads50 minIoThreads50/ 如果采用这个设置之后“黑色30秒”现象几乎不出现就能验证问题出在这个地方。现在主站www.cnblogs.com已经使用了这个设置需要观察一段时间进行验证。 【启示】 1) 通过Windows性能监视器监视\ASP.NET\Requests Queued可以直观地评估ASP.NET应用程序的吞吐能力throughput。 2) 通过ASP.NET异步编程async/await可以有效减少可用线程紧张造成的请求排队问题。 2、为什么Arrival Rate会下降 上图中的橙色线条 这是“黑色30秒”问题中最让人不解的地方ASP.NET中请求再怎么排队怎么会造成到达HTTP.SYS的请求数下降呢一开始我们总是不相信是请求排队引起的Arrival Rate下降但是监视图中却铁证如山。 写这篇博客之前我们突然想通了之前忽略了一个地方——当你打这篇博文时第1个请求是html页面如果这个请求得到正常响应浏览器在加载这个页面时会发出多个ajax请求如果第1个请求被排队浏览器处于等待状态后续的ajax请求就不会发出这样到达HTTP.SYS的请求数就会下降。这也解释了为什么有时会在“黑色30秒”的中间阶段Arrival Rate会飙高正是因为当时被排队的请求所对应的页面中有很多ajax当它结束排队被执行后后续的很多ajax请求可能排队的很多是这样的请求到达了HTTP.SYS。 于是我们相信了是请求排队引起的Arrival Rate下降。 【启示】 不能把目光局限于当前看到的问题表现而要综合考虑将诸多因素联系起来理清各种现象之间的关系。 3、QPS下降 与Arrival Rate下降同理QPS(Requests/Sec)与Arrival Rate是直接相关的成正比关系。 于是QPS下降也是因为请求排队。 4、CPU消耗下降 也是同理Arrival Rate与QPS下降说明CPU要干的活少了自然消耗就下降。 于是CPU消耗下降也是因为请求排队。 5、Current Connections上升 Current Connections是请求排队的一个直接表现请求还没被执行连接当然会保持着。 于是Current Connection上升也是因为请求排队。 6、看一个新指标Requests Executing 上图绿色的线条表示的是Requests Executing 在请求排队的期间正在被ASP.NET执行的请求数Requests Executing在增加说明随着被释放出来的线程增多以及更多的新线程被创建排列中的请求正在被越来越多地执行。这从侧面说明了执行中的线程可能是正常的没有被卡住。接下来的IIS日志信息会进一步验证这一点 于是Requests Executing在增加也是因为请求被排队而且说明这个排队是正常的没有哪个地方卡住了。 7、再来看看IIS日志中请求的time-taken 在“黑色30秒”阶段IIS日志中没有time-taken超过1s的请求这说明了什么说明了正在被执行的请求处理速度很快没有什么地方被卡住。。。除了因为可用线程不够请求被排队。 于是IIS日志说明除了请求排队其他地方一切正常。 【总结】 如果把“黑色30秒”问题归因于ASP.NET线程问题除了30秒左右的这个时间其他问题表现都得到了更合理的解释。 写这篇博客之前我们当时觉得ASP.NET线程问题引起“黑色30秒”问题的可能性是80%写完这7点分析之后我们觉得可能性是99%除非这次分析的“黑色30秒”与之前的“黑色30秒”不是同一个问题。 现在还需要我们使用新设置(maxWorkerThreads100, maxIoThreads100, minWorkerThreads50, minIoThreads50)之后的验证。 大结局即将来临重要的可能不是结局是什么而是其中的过程我们分享的也是解决问题的过程。 转载于:https://www.cnblogs.com/AmilyWilly/p/4791742.html
