异步编程 In .NET

作者:金牛区福生殡葬服务部 来源:www.cdfsbz.com 发布时间:2017-09-11 14:01:08
异步编程 In .NET  在之前写的一篇关于async和await的前世今生的文章之后,大家似乎在async和await提高网站处理能力方面还有一些疑问,博客园本身也做了不少的尝试。今天我们再来回答一下这个问题,同时我们会做一个async和await在WinForm中的尝试,并且对比在4.5之前的异步编程模式APM/EAP和async/await的区别,最后我们还会探讨在不同线程之间交互的问题。

  IIS存在着处理能力的问题,但是WinForm却是UI响应的问题,并且WinForm的UI线程至始至终都是同一个,所以两者之间有一定的区别。有人会问,现在还有人写WinForm吗?好吧,它确是一个比较老的东西呢,不如WPF炫,技术也不如WPF先进,但是从架构层面来讲,不管是Web,还是WinForm,又或是WPF,Mobile,这些都只是表现层,不是么?现在的大型系统一般桌面客户端,Web端,手机,平板端都会涉及,这也是为什么会有应用层,服务层的存在。我们在这谈论的ASP.NET MVC,WinForm,WFP,Android/IOS/WP 都是表现层,在表现层我们应该只处理与“表现”相关的逻辑,任何与业务相关的逻辑应该都是放在下层处理的。关于架构的问题,我们后面再慢慢深入,另外别说我没有提示您,我们今天还会看到.NET中另一个已经老去的技术Web Service。

  还得提示您,文章内容有点长,涉及的知识点比较多,所以,我推荐:”先顶后看“ ,先顶后看是21世纪看长篇的首选之道,是良好沟通的开端,想知道是什么会让你与众不同吗?想知道为什么上海今天会下这么大的雨么?请记住先顶后看,你顶的不是我的文章,而是我们冒着大雨还要去上班的可贵精神!先顶后看,你值得拥有!

  首先响应能力并不完全是说我们程序性能的问题,有时候可能你的程序没有任何问题,而且精心经过优化,可是响应能力还是没有上去,网站性能分析是一个复杂的活,有时候只能靠经验和不断的尝试才能达到比较好的效果。当然我们今天讨论的主要是IIS的处理能力,或者也可能说是IIS的性能,但绝非代码本身的性能。即使async/await能够提高IIS的处理能力,但是对于用户来说整个页面从发起请求到页面渲染完成的这些时间,是不会因为我们加了async/await之后产生多大变化的。

  另外异步的ASP.NET并非只有async/await才可以做的,ASP.NET在Web Form时代就已经有异步Page了,包括ASP.NET MVC不是也有异步的Controller么?async/await 很新,很酷,但是它也只是在原有一技术基础上做了一些改进,让程序员们写起异步代码来更容易了。大家常说微软喜欢新瓶装旧酒,至少我们要看到这个新瓶给我们带来了什么,不管是任何产品,都不可能一开始就很完美,所以不断的迭代更新,也可以说是一种正确做事的方式。

ASP.NET并行处理的步骤

  ASP.NET是如何在IIS中工作的一文已经很详细的介绍了一个请求是如何从客户端到服务器的HTTP.SYS最后进入CLR进行处理的(强烈建议不了解这一块的同学先看这篇文章,有助于你理解本小节),但是所有的步骤都是基于一个线程的假设下进行的。IIS本身就是一个多线程的工作环境,如果我们从多线程的视角来看会发生什么变化呢?我们首先来看一下下面这张图。注意:我们下面的步骤是建立在IIS7.0以后的集成模式基础之上的。(注:下面这张图在dudu的提醒之后,重新做了一些搜索工作,做了一些改动,w3dt这一步来自于博客园团队对问题的不断探索,详情可以点这里)

  我们再来梳理一下上面的步骤:

所有的请求最开始是由HTTP.SYS接收的,HTTP.SYS内部有一个队列维护着这些请求,这个队列的request的数量大于一定数量(默认是1000)的时候,HTTP.SYS就会直接返回503状态(服务器忙),这是我们的第一个阀门。性能计数指标:“Http Service Request Queues\CurrentQueueSize”

由w3dt负责把请求从HTTP.SYS 的队列中放到一个对应端口的队列中,据非官方资料显示该队列长度为能为20(该队列是非公开的,没有文档,所以也没有性能计数器)。

IIS 的IO线程从上一步的队列中获取请求,如果是需要ASP.NET处理的,就会转交给CLR 线程池的Worker 线程,IIS的IO线程继续返回重复做该步骤。CLR 线程池的Worker线程数量是第二个阀门。

当CLR中正在被处理的请求数据大于一定值(最大并行处理请求数量,.NET4以后默认是5000)的时候,从IO线程过来的请求就不会直接交给Worker线程,而是放到一个进程池级别的一个队列了,等到这个数量小于临界值的时候,才会把它再次交给Worker线程去处理。这是我们的第三个阀门。

上一步中说到的那个进程池级别的队列有一个长度的限制,可以通过web.config里面的processModel/requestQueueLimit来设置。这可以说也是一个阀门。当正在处理的数量大于所允许的最大并行处理请求数量的时候,我们就会得到503了。可以通过性能计数指标:“ASP.NET v4.0.30319\Requests Queued” 来查看该队列的长度。

哪些因素会控制我们的响应能力

  从上面我们提到了几大阀门中,我们可以得出下面的几个数字控制或者说影响着我们的响应能力。

HTTP.SYS队列的长度

CLR线程池最大Worker线程数量

最大并行处理请求数量

进程池级别队列所允许的长度

HTTP.SYS队列的长度

  这个我觉得不需要额外解释,默认值是1000。这个值取决于我们我们后面IIS IO线程和Worker线程的处理速度,如果它们两个都处理不了,这个数字再大也没有用。因为最后他们会被存储到进程池级别的队列中,所以只会造成内存的浪费。

最大Worker线程数量

  这个值是可以在web.config中进行配置的。

  maxWorkerThreads: CLR中真实处理请求的最大Worker线程数量

  minWorkerThreads:CLR中真实处理请求的最小Worker线程数量

  minWorkerThreads的默认值是1,合理的加大他们可以避免不必要的线程创建和销毁工作。

最大并行处理请求数量

  进程池级别的队列给我们的CLR一定的缓冲,这里面要注意的是,这个队列还没有进入到CLR,所以它不会占用我们托管环境的任何资源,也就是把请求卡在了CLR的外面。我们需要在aspnet.config级别进行配置,我们可以在.net fraemwork的安装目录下找到它。一般是 C:\Windows\Microsoft.NET\Framework\v4.0.30319 如果你安装的是4.0的话。

  maxConcurrentRequestPerCPU: 每个CPU所允许的最大并行处理请求数量,当CLR中worker线程正在处理的请求之和大于这个数时,从IO线程过来的请求就会被放到我们进程池级别的队列中。

  maxConcurrentThreadsPerCPU: 设置为0即禁用。

  requestQueue: 进程池级别队列所允许的长度。  

async和await 做了什么?

企业建站2800元起,携手武汉肥猫科技,做一个有见地的颜值派!更多优惠请戳:荆门SEO http://jingmen.4567w.com

  • 上一篇:Python时间日期操作大全
  • 下一篇:最后一页
  • 
    COPYRIGHT © 2015 金牛区福生殡葬服务部 ALL RIGHTS RESERVED.
    购买cdfsbz.com友情链接、项目合作请联系客服QQ:2500-38-100 邮箱:2500-38-100#QQ.com(#换@)
    本站所有原创信息,未经许可请勿任意转载或复制使用 网站地图 技术支持:肥猫科技
    精彩专题:网站建设
    购买本站友情链接、项目合作请联系客服QQ:2500-38-100