Lim*_*ing 9 asp.net iis performance threadpool
我只想在这里澄清一些概念.如果有人愿意在这个问题上分享他们的专业知识,我们非常感激.
以下是我对IIS如何与线程相关的理解,如果我错了,请纠正我.
据我了解,对于IIS 6.0(我现在将离开IIS 7.0),Web浏览器发出请求,获取HTTP.sys内核驱动程序,HTTP.sys将其移交给IIS 6.0的线程池(I/O线程？)这样自由了.
IIS 6.0的线程返回将其交给ASP.NET,后者将一个临时的HSE_STATUS_PENDING返回到IIS 6.0,从而释放IIS 6.0线程,然后将其转发到CLR线程.
当ASP.NET在CLR线程池中选择一个空闲线程时,它会执行该请求.如果没有可用的CLR线程,它将在应用程序级别队列中排队(性能不佳)
基于之前的理解,我的问题如下.
在同步模式下,这是否意味着每1个CLR线程有1个请求？
*)如果是这样,可以在1个CPU上提供多少个CONCURRENT请求？或者我应该反过来问？如何在每个CPU上允许CLR线程？比如,允许50个CLR线程,这是否意味着它在任何给定时间限制为50个请求？困惑.
如果我将"processModle"配置中的"requestQueueLimit"设置为5000,那真的是什么意思？您可以在应用程序队列中排队5000个请求吗？这不是很糟糕吗？由于应用程序队列性能不佳,为什么要将它设置得如此之高？
如果您正在编程异步页面,那么它确实在上面的过程中从哪里开始获益？
我研究并看到默认情况下,IIS 6.0的线程池大小为256.5000并发请求到来时,由256处理的IIS 6.0线程,然后每256个线程,双手其关闭,而我猜CLR线程甚至默认情况下降低 这本身不是异步的吗？有点困惑.此外,瓶颈何时何地开始以同步模式出现？并在异步模式？(不确定我是否有任何意义,我只是感到困惑).
当IIS threadpool(所有256个)忙时会发生什么？
当所有CLR线程都忙时会发生什么？(我假设所有请求都在应用程序级别队列中排队)
当应用程序队列超过requestQueueLimit时会发生什么？
非常感谢您的阅读,非常感谢您在这方面的专业知识.
你对CLR的切换过程很有见,但这里的事情变得有趣:
如果请求的每一步都是CPU绑定的/否则是同步的,是的:该请求将在该生命周期内吸收该线程.
但是,如果请求处理的任何部分处理异步甚至任何与纯托管代码之外的任何I/O相关的任务(数据库连接,文件读/写等),则有可能(如果不可能)发生这种情况:
请求进入CLR-land,由线程A接收
请求调用文件系统
在引擎盖下,向非托管代码的转换发生在某个级别,这导致以类似回调的方式分配IO完成端口线程(不同于普通线程池线程).
一旦发生切换,线程A就会返回到线程池,在那里它可以为请求提供服务.
一旦I/O任务完成,执行就会重新排队,让我们说线程A正忙 - 线程B接收请求.
这种"有趣"的行为也称为"线程敏捷",如果可以的话,这是避免在ASP.NET应用程序中使用ANYTHING作为Thread Static的一个原因.
现在,对你的一些问题:
请求队列限制是在请求开始变平之前可以"在线"的请求数.如果您有一个异常"突发"的应用程序,在那里您可能会收到很多非常短暂的请求,将此设置为高可以防止请求被丢弃,因为它们会聚集在队列中,但排放速度相同.
异步处理程序允许您创建上述场景具有的相同"在完成时给我打电话"的行为类型; 例如,如果你说需要进行一个Web服务调用,那么通过默认阻止一些HttpWebRequest调用同步调用它直到完成,锁定该线程直到它完成.异步调用相同的服务(或异步处理程序,任何Begin/EndXXX模式...)允许您控制实际被绑定的人 - 您的调用线程可以继续执行操作,直到该Web服务返回,这可能实际上是在请求已完成.
有一点需要注意的是,只有一个ThreadPool - 所有非IO线程都是从那里拉出的,所以如果你把所有东西都移到异步处理中,你可能会因为耗尽线程池做背景工作而不是处理请求而咬你自己.
| 归档时间： |
|
| 查看次数： |
1742 次 |
| 最近记录： |