IIS处理并发请求时出现的问题及解决

老唯

于 2020-08-13 21:09:56 发布

阅读量1.3k

点赞数 1

分类专栏：服务器相关文章标签： iis并发

原文链接：https://www.cnblogs.com/hgamezoom/p/3082538.html

版权

服务器相关专栏收录该内容

12 篇文章 0 订阅

订阅专栏

原文来自：https://www.cnblogs.com/hgamezoom/p/3082538.html

一个ASP.NET项目在部署到生产环境时，当用户并发量达到200左右时，IIS出现了明显的请求排队现象，发送的请求都进入等待，无法及时响应，系统基本处于不可用状态。因经验不足，花了很多时间精力解决这个问题，本文记录了我查找问题的过程和最后解决方案，供大家参考。

软硬件环境：

IBM刀片服务器，Intel至强处理器，4物理核，16个逻辑核心，内存32G

Windows Server2008 Enterprise R2， ASP.NET 4.0 Webform IIS7.5 集成模式

当发现请求明显延迟，没有被即时处理的现象，首先就要查看Windows自带的性能日志Performance Monitor。

由于我注意到只有对于.aspx或.ashx的请求才会延迟，而.htm或.jpg文件都是即时响应的，所以很明显问题出在ASP.NET上，于是我选择了性能监视器中的ASP.NET 4.0中的2个主要计数器：Requests Current（当前请求数）, Requests Queued（被排队的请求数）进行观察。通过观察发现，当前请求数达到200左右时，被排队的请求数就从0开始上升，一直到50左右，如果请求数继续上升，则被排队数也随之上升。当被排队的请求数>0时，就意味着这个时候去访问任何.aspx页面，页面都会处于长时间等待中，没有任何响应，直到IIS处理完了其他请求，才会开始处理队列中的请求。也就是说，当排队数长期>0时，系统基本处于不可用的状态。

由于这个系统的页面布局比较复杂，采用了大量的Ajax+.ashx的方式，将内容分批展示在页面上，所以对服务器的请求总数会比传统aspx模式来的多一些，一个页面全部加载完毕可能需要5-10秒，但我想这不应该是造成问题的主要原因，就算系统性能较差，IIS也应该足以承受这么小的并发量的。

为探究到底是系统写的有问题，还是IIS本身的问题，我抛开我们的系统，写了一个简单的页面，就一个aspx文件，page_load里sleep 10秒。假设这就是一个性能比较差的网站，每个页面都要10秒才能展现，我将其部署在IIS上测试其性能，我使用的是Microsoft Web Application Stress Tool，模拟发起80个线程，每个连接有4个Socket，总共相当于320个并发请求。

测试开始后，可以从下图中看到，当前请求数立刻攀升到300左右（图中红线），然后队列中的请求数也上升到300左右（图中绿线），就是说在300个并发请求下，几乎所有的请求都被排队了，系统基本不可用，通过简单的测试，这个问题已经得以重现了。

随着时间推移，发现绿线慢慢减少，从300下降到100多，就是系统可用性渐渐提高，有一部分用户可以正常使用，但大部分还在排队。

过了6，7分钟，队列中的请求数下降到0左右，并有一些小幅波动。这个时候大部分请求可以被正常处理了。按照这个现象分析的话，应该是IIS发现有大量请求在队列中，就会试图增加处理线程数以满足要求，但是增长速度有些缓慢。

那是不是系统经过了6，7分钟的适应期之后，以后就一直可以在这个并发量下稳定运作了呢？事实并非如此。我将压力测试停了几秒，当服务器的请求数降为0以后，再重新开启320个请求的测试，IIS如何表现？从下图可以看到，只要请求数有明显上升，则等待队列又开始达到最高值，然后缓慢下降，重复上面的过程。总结下来就是，当出现较大并发时，IIS的处理请求能力完全跟不上，需要很长时间才能开出足够的线程。