当前位置: 棋牌电玩游戏平台 > 独家报道 > 正文

【转】异步编制程序 In .NET

时间:2019-08-20 01:45来源:独家报道
概述 转自: 【转】异步编程 In .NET,异步编程in.net 概述 在之前写的一篇关于async和await的前世今生的文章之后,大家似乎在async和await提高网站处理能力方面还有一些疑问,博客园本身也

概述

转自:

【转】异步编程 In .NET,异步编程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世纪看长篇的首选之道,是良好沟通的开端,想知道是什么会让你与众不同吗?想知道为什么上海今天会下这么大的雨么?请记住先顶后看,你顶的不是我的文章,而是我们冒着大雨还要去上班的可贵精神!先顶后看,你值得拥有!

  在之前写的一篇关于async和await的前世今生的文章之后,大家似乎在async和await提高网站处理能力方面还有一些疑问,博客园本身也做了不少的尝试。今天我们再来回答一下这个问题,同时我们会做一个async和await在WinForm中的尝试,并且对比在4.5之前的异步编程模式APM/EAP和async/await的区别,最后我们还会探讨在不同线程之间交互的问题。

概述

  在之前写的一篇关于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世纪看长篇的首选之道,是良好沟通的开端,想知道是什么会让你与众不同吗?想知道为什么上海今天会下这么大的雨么?请记住先顶后看,你顶的不是我的文章,而是我们冒着大雨还要去上班的可贵精神!先顶后看,你值得拥有!

目录

  • async/await如何提升IIS响应能力
    • 并行处理的步骤
    • 哪些因素影响了我们的响应能力
    • async 和 await做了什么?
    • 几点建议
  • 早期Web Service的异步模式APM
    • 当WinForm遇到Web Service
    • WinForm异步调用Web Service
  • APM异步编程详解
    • 线程问题
    • 从Delegate开始
    • 再次认识APM
  • EAP(Event-Based Asynchroronous Pattern)
    • 线程问题
  • async/await 给WinForm编程带来了什么?
  • 不同线程之间通讯的问题
    • 万能的InvokeI
    • SynchronizationContex上下文同步对象
  • 小结
  • 引用 & 扩展阅读

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

目录

  • async/await如何提升IIS响应能力
    • 并行处理的步骤
    • 哪些因素影响了我们的响应能力
    • async 和 await做了什么?
    • 几点建议
  • 早期Web Service的异步模式APM
    • 当WinForm遇到Web Service
    • WinForm异步调用Web Service
  • APM异步编程详解
    • 线程问题
    • 从Delegate开始
    • 再次认识APM
  • EAP(Event-Based Asynchroronous Pattern)
    • 线程问题
  • async/await 给WinForm编程带来了什么?
  • 不同线程之间通讯的问题
    • 万能的InvokeI
    • SynchronizationContex上下文同步对象
  • 小结
  • 引用 & 扩展阅读

async/await如何提升IIS处理能力

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

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

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

async/await如何提升IIS处理能力

  首先响应能力并不完全是说我们程序性能的问题,有时候可能你的程序没有任何问题,而且精心经过优化,可是响应能力还是没有上去,网站性能分析是一个复杂的活,有时候只能靠经验和不断的尝试才能达到比较好的效果。当然我们今天讨论的主要是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这一步来自于博客园团队对问题的不断探索,详情可以点这里)

图片 1

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

目录

  • async/await如何提升IIS响应能力
    • 并行处理的步骤
    • 哪些因素影响了我们的响应能力
    • async 和 await做了什么?
    • 几点建议
  • 早期Web Service的异步模式APM
    • 当WinForm遇到Web Service
    • WinForm异步调用Web Service
  • APM异步编程详解
    • 线程问题
    • 从Delegate开始
    • 再次认识APM
  • EAP(Event-Based Asynchroronous Pattern)
    • 线程问题
  • async/await 给WinForm编程带来了什么?
  • 不同线程之间通讯的问题
    • 万能的InvokeI
    • SynchronizationContex上下文同步对象
  • 小结
  • 引用 & 扩展阅读

ASP.NET并行处理的步骤

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

图片 2

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

  1. 所有的请求最开始是由HTTP.SYS接收的,HTTP.SYS内部有一个队列维护着这些请求,这个队列的request的数量大于一定数量(默认是1000)的时候,HTTP.SYS就会直接返回503状态(服务器忙),这是我们的第一个阀门。性能计数指标:“Http Service Request QueuesCurrentQueueSize
  2. 由w3dt负责把请求从HTTP.SYS 的队列中放到一个对应端口的队列中,据非官方资料显示该队列长度为能为20(该队列是非公开的,没有文档,所以也没有性能计数器)。
  3. IIS 的IO线程从上一步的队列中获取请求,如果是需要ASP.NET处理的,就会转交给CLR 线程池的Worker 线程,IIS的IO线程继续返回重复做该步骤。CLR 线程池的Worker线程数量是第二个阀门。
  4. 当CLR中正在被处理的请求数据大于一定值(最大并行处理请求数量,.NET4以后默认是5000)的时候,从IO线程过来的请求就不会直接交给Worker线程,而是放到一个进程池级别的一个队列了,等到这个数量小于临界值的时候,才会把它再次交给Worker线程去处理。这是我们的第三个阀门。
  5. 上一步中说到的那个进程池级别的队列有一个长度的限制,可以通过web.config里面的processModel/requestQueueLimit来设置。这可以说也是一个阀门。当正在处理的数量大于所允许的最大并行处理请求数量的时候,我们就会得到503了。可以通过性能计数指标:“ASP.NET v4.0.30319Requests Queued” 来查看该队列的长度。

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

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

HTTP.SYS队列的长度

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

最大Worker线程数量

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

图片 3

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

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

最大并行处理请求数量

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

图片 4

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

async/await如何提升IIS处理能力

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

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

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

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

  1. HTTP.SYS队列的长度
  2. CLR线程池最大Worker线程数量
  3. 最大并行处理请求数量
  4. 进程池级别队列所允许的长度

HTTP.SYS队列的长度

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

最大Worker线程数量

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

图片 5

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

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

最大并行处理请求数量

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

图片 6

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

async和await 做了什么?

  我们终于要切入正题了,拿ASP.NET MVC举例,如果不采用async的Action,那么毫无疑问,它是在一个Woker线程中执行的。当我们访问一些web service,或者读文件的时候,这个Worker线程就会被阻塞。假设我们这个Action执行时间一共是100ms,其它访问web service花了80ms,理想情况下一个Worker线程一秒可以响应10个请求,假设我们的maxWorkerThreads是10,那我们一秒内总是可响应请求就是100。如果说我们想把这个可响应请求数升到200怎么做呢?

  有人会说,这还不简单,把maxWorkerThreads调20不就行了么? 其实我们做也没有什么 问题,确实是可以的,而且也确实能起到作用。那我们为什么还要大费周章的搞什么 async/await呢?搞得脑子都晕了?async/await给我们解决了什么问题?它可以在我们访问web service的时候把当前的worker线程放走,将它放回线程池,这样它就可以去处理其它的请求了。等到web service给我们返回结果了,会再到线程池中随机拿一个新的woker线程继续往下执行。也就是说我们减少了那一部分等待的时间,充份利用了线程。

    我们来对比一下使用async/awit和不使用的情况,

  不使用async/await: 20个woker线程1s可以处理200个请求。

  那转换成总的时间的就是 20 * 1000ms =  20000ms,
  其中等待的时间为 200 * 80ms = 16000ms。
  也就是说使用async/await我们至少节约了16000ms的时间,这20个worker线程又会再去处理请求,即使按照每个请求100ms的处理时间我们还可以再增加160个请求。而且别忘了100ms是基于同步情况下,包括等待时间在内的基础上得到的,所以实际情况可能还要多,当然我们这里没有算上线程切换的时间,所以实际情况中是有一点差异的,但是应该不会很大,因为我们的线程都是基于线程池的操作。
  所有结果是20个Worker线程不使用异步的情况下,1s能自理200个请求,而使用异步的情况下可以处理360个请求,立马提升80%呀!采用异步之后,对于同样的请求数量,需要的Worker线程数据会大大减少50%左右,一个线程至少会在堆上分配1M的内存,如果是1000个线程那就是1G的容量,虽然内存现在便宜,但是省着总归是好的嘛,而且更少的线程是可以减少线程池在维护线程时产生的CPU消耗的。另:dudu分享 CLR1秒之内只能创建2个线程。

  注意:以上数据并非真实测试数据,真实情况一个request的时间也并非100ms,花费在web service上的时间也并非80ms,仅仅是给大家一个思路:),所以这里面用了async和await之后对响应能力有多大的提升和我们原来堵塞在这些IO和网络上的时间是有很大的关系的。

ASP.NET并行处理的步骤

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

图片 7

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

  1. 所有的请求最开始是由HTTP.SYS接收的,HTTP.SYS内部有一个队列维护着这些请求,这个队列的request的数量大于一定数量(默认是1000)的时候,HTTP.SYS就会直接返回503状态(服务器忙),这是我们的第一个阀门。性能计数指标:“Http Service Request QueuesCurrentQueueSize
  2. 由w3dt负责把请求从HTTP.SYS 的队列中放到一个对应端口的队列中,据非官方资料显示该队列长度为能为20(该队列是非公开的,没有文档,所以也没有性能计数器)。
  3. IIS 的IO线程从上一步的队列中获取请求,如果是需要ASP.NET处理的,就会转交给CLR 线程池的Worker 线程,IIS的IO线程继续返回重复做该步骤。CLR 线程池的Worker线程数量是第二个阀门。
  4. 当CLR中正在被处理的请求数据大于一定值(最大并行处理请求数量,.NET4以后默认是5000)的时候,从IO线程过来的请求就不会直接交给Worker线程,而是放到一个进程池级别的一个队列了,等到这个数量小于临界值的时候,才会把它再次交给Worker线程去处理。这是我们的第三个阀门。
  5. 上一步中说到的那个进程池级别的队列有一个长度的限制,可以通过web.config里面的processModel/requestQueueLimit来设置。这可以说也是一个阀门。当正在处理的数量大于所允许的最大并行处理请求数量的时候,我们就会得到503了。可以通过性能计数指标:“ASP.NET v4.0.30319Requests Queued” 来查看该队列的长度。

async和await 做了什么?

  我们终于要切入正题了,拿ASP.NET MVC举例,如果不采用async的Action,那么毫无疑问,它是在一个Woker线程中执行的。当我们访问一些web service,或者读文件的时候,这个Worker线程就会被阻塞。假设我们这个Action执行时间一共是100ms,其它访问web service花了80ms,理想情况下一个Worker线程一秒可以响应10个请求,假设我们的maxWorkerThreads是10,那我们一秒内总是可响应请求就是100。如果说我们想把这个可响应请求数升到200怎么做呢?

  有人会说,这还不简单,把maxWorkerThreads调20不就行了么? 其实我们做也没有什么 问题,确实是可以的,而且也确实能起到作用。那我们为什么还要大费周章的搞什么 async/await呢?搞得脑子都晕了?async/await给我们解决了什么问题?它可以在我们访问web service的时候把当前的worker线程放走,将它放回线程池,这样它就可以去处理其它的请求了。等到web service给我们返回结果了,会再到线程池中随机拿一个新的woker线程继续往下执行。也就是说我们减少了那一部分等待的时间,充份利用了线程。

    我们来对比一下使用async/awit和不使用的情况,

  不使用async/await: 20个woker线程1s可以处理200个请求。

  那转换成总的时间的就是 20 * 1000ms =  20000ms,
  其中等待的时间为 200 * 80ms = 16000ms。
  也就是说使用async/await我们至少节约了16000ms的时间,这20个worker线程又会再去处理请求,即使按照每个请求100ms的处理时间我们还可以再增加160个请求。而且别忘了100ms是基于同步情况下,包括等待时间在内的基础上得到的,所以实际情况可能还要多,当然我们这里没有算上线程切换的时间,所以实际情况中是有一点差异的,但是应该不会很大,因为我们的线程都是基于线程池的操作。
  所有结果是20个Worker线程不使用异步的情况下,1s能自理200个请求,而使用异步的情况下可以处理360个请求,立马提升80%呀!采用异步之后,对于同样的请求数量,需要的Worker线程数据会大大减少50%左右,一个线程至少会在堆上分配1M的内存,如果是1000个线程那就是1G的容量,虽然内存现在便宜,但是省着总归是好的嘛,而且更少的线程是可以减少线程池在维护线程时产生的CPU消耗的。另:dudu分享 CLR1秒之内只能创建2个线程。

  注意:以上数据并非真实测试数据,真实情况一个request的时间也并非100ms,花费在web service上的时间也并非80ms,仅仅是给大家一个思路:),所以这里面用了async和await之后对响应能力有多大的提升和我们原来堵塞在这些IO和网络上的时间是有很大的关系的。

几点建议

  看到这里,不知道大家有没有得到点什么。首先第一点我们要知道的是async/await不是万能药,不们不能指望光写两个光键字就希望性能的提升。要记住,一个CPU在同一时间段内是只能执行一个线程的。所以这也是为什么async和await建议在IO或者是网络操作的时候使用。我们的MVC站点访问WCF或者Web Service这种场景就非常的适合使用异步来操作。在上面的例子中80ms读取web service的时间,大部份时间都是不需要cpu操作的,这样cpu才可以被其它的线程利用,如果不是一个读取web service的操作,而是一个复杂计算的操作,那你就等着cpu爆表吧。

  第二点是,除了程序中利用异步,我们上面讲到的关于IIS的配置是很重要的,如果使用了异步,请记得把maxWorkerThreads和maxConcurrentRequestPerCPU的值调高试试。

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

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

  1. HTTP.SYS队列的长度
  2. CLR线程池最大Worker线程数量
  3. 最大并行处理请求数量
  4. 进程池级别队列所允许的长度

HTTP.SYS队列的长度

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

最大Worker线程数量

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

图片 8

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

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

最大并行处理请求数量

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

图片 9

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

几点建议

  看到这里,不知道大家有没有得到点什么。首先第一点我们要知道的是async/await不是万能药,不们不能指望光写两个光键字就希望性能的提升。要记住,一个CPU在同一时间段内是只能执行一个线程的。所以这也是为什么async和await建议在IO或者是网络操作的时候使用。我们的MVC站点访问WCF或者Web Service这种场景就非常的适合使用异步来操作。在上面的例子中80ms读取web service的时间,大部份时间都是不需要cpu操作的,这样cpu才可以被其它的线程利用,如果不是一个读取web service的操作,而是一个复杂计算的操作,那你就等着cpu爆表吧。

  第二点是,除了程序中利用异步,我们上面讲到的关于IIS的配置是很重要的,如果使用了异步,请记得把maxWorkerThreads和maxConcurrentRequestPerCPU的值调高试试。

 早期对Web service的异步编程模式APM

  讲完我们高大上的async/await之后,我们来看看这个技术很老,但是概念确依旧延续至今的Web Service。 我们这里所说的针对web service的异步编程模式不是指在服务器端的web service本身,而是指调用web service的客户端。大家知道对于web service,我们通过添加web service引用或者.net提供的生成工具就可以生成相应的代理类,可以让我们像调用本地代码一样访问web service,而所生成的代码类中对针对每一个web service方法生成3个对应的方法,比如说我们的方法名叫DownloadContent,除了这个方法之外还有BeginDownloadContent和EndDownloadContent方法,而这两个就是我们今天要说的早期的异步编程模式APM(Asynchronous Programming Model)。下面就来看看我们web service中的代码,注意我们现在的项目都是在.NET Framework3.5下实现的。

 PageContent.asmx的代码

public class PageContent : System.Web.Services.WebService
{
    [WebMethod]
    public string DownloadContent(string url)
    {
        var client = new System.Net.WebClient();
        return client.DownloadString(url);
    }
}

  注意我们web service中的DownloadContent方法调用的是WebClient的同步方法,WebClient也有异步方法即:DownloadStringAsync。但是大家要明白,不管服务器是同步还是异步,对于客户端来说调用了你这个web service都是一样的,就是得等你返回结果。

  当然,我们也可以像MVC里面的代码一样,把我们的服务器端也写成异步的。那得到好处的是那个托管web service的服务器,它的处理能力得到提高,就像ASP.NET一样。如果我们用JavaScript去调用这个Web Service,那么Ajax(Asynchronous Javascript XML)就是我们客户端用到的异步编程技术。如果是其它的客户端呢?比如说一个CS的桌面程序?我们需要异步编程么?

async和await 做了什么?

  我们终于要切入正题了,拿ASP.NET MVC举例,如果不采用async的Action,那么毫无疑问,它是在一个Woker线程中执行的。当我们访问一些web service,或者读文件的时候,这个Worker线程就会被阻塞。假设我们这个Action执行时间一共是100ms,其它访问web service花了80ms,理想情况下一个Worker线程一秒可以响应10个请求,假设我们的maxWorkerThreads是10,那我们一秒内总是可响应请求就是100。如果说我们想把这个可响应请求数升到200怎么做呢?

  有人会说,这还不简单,把maxWorkerThreads调20不就行了么? 其实我们做也没有什么 问题,确实是可以的,而且也确实能起到作用。那我们为什么还要大费周章的搞什么 async/await呢?搞得脑子都晕了?async/await给我们解决了什么问题?它可以在我们访问web service的时候把当前的worker线程放走,将它放回线程池,这样它就可以去处理其它的请求了。等到web service给我们返回结果了,会再到线程池中随机拿一个新的woker线程继续往下执行。也就是说我们减少了那一部分等待的时间,充份利用了线程。

    我们来对比一下使用async/awit和不使用的情况,

  不使用async/await: 20个woker线程1s可以处理200个请求。

  那转换成总的时间的就是 20 * 1000ms =  20000ms,
  其中等待的时间为 200 * 80ms = 16000ms。
  也就是说使用async/await我们至少节约了16000ms的时间,这20个worker线程又会再去处理请求,即使按照每个请求100ms的处理时间我们还可以再增加160个请求。而且别忘了100ms是基于同步情况下,包括等待时间在内的基础上得到的,所以实际情况可能还要多,当然我们这里没有算上线程切换的时间,所以实际情况中是有一点差异的,但是应该不会很大,因为我们的线程都是基于线程池的操作。
  所有结果是20个Worker线程不使用异步的情况下,1s能自理200个请求,而使用异步的情况下可以处理360个请求,立马提升80%呀!采用异步之后,对于同样的请求数量,需要的Worker线程数据会大大减少50%左右,一个线程至少会在堆上分配1M的内存,如果是1000个线程那就是1G的容量,虽然内存现在便宜,但是省着总归是好的嘛,而且更少的线程是可以减少线程池在维护线程时产生的CPU消耗的。另:dudu分享 CLR1秒之内只能创建2个线程。

  注意:以上数据并非真实测试数据,真实情况一个request的时间也并非100ms,花费在web service上的时间也并非80ms,仅仅是给大家一个思路:),所以这里面用了async和await之后对响应能力有多大的提升和我们原来堵塞在这些IO和网络上的时间是有很大的关系的。

 早期对Web service的异步编程模式APM

  讲完我们高大上的async/await之后,我们来看看这个技术很老,但是概念确依旧延续至今的Web Service。 我们这里所说的针对web service的异步编程模式不是指在服务器端的web service本身,而是指调用web service的客户端。大家知道对于web service,我们通过添加web service引用或者.net提供的生成工具就可以生成相应的代理类,可以让我们像调用本地代码一样访问web service,而所生成的代码类中对针对每一个web service方法生成3个对应的方法,比如说我们的方法名叫DownloadContent,除了这个方法之外还有BeginDownloadContent和EndDownloadContent方法,而这两个就是我们今天要说的早期的异步编程模式APM(Asynchronous Programming Model)。下面就来看看我们web service中的代码,注意我们现在的项目都是在.NET Framework3.5下实现的。

 PageContent.asmx的代码

1
2
3
4
5
6
7
8
9
public class PageContent : System.Web.Services.WebService
{
    [WebMethod]
    public string DownloadContent(string url)
    {
        var client = new System.Net.WebClient();
        return client.DownloadString(url);
    }
}

  注意我们web service中的DownloadContent方法调用的是WebClient的同步方法,WebClient也有异步方法即:DownloadStringAsync。但是大家要明白,不管服务器是同步还是异步,对于客户端来说调用了你这个web service都是一样的,就是得等你返回结果。

  当然,我们也可以像MVC里面的代码一样,把我们的服务器端也写成异步的。那得到好处的是那个托管web service的服务器,它的处理能力得到提高,就像ASP.NET一样。如果我们用JavaScript去调用这个Web Service,那么Ajax(Asynchronous Javascript XML)就是我们客户端用到的异步编程技术。如果是其它的客户端呢?比如说一个CS的桌面程序?我们需要异步编程么?

当WinForm遇上Web Service

  WinForm不像托管在IIS的ASP.NET网站,会有一个线程池管理着多个线程来处理用户的请求,换个说法ASP.NET网站生来就是基于多线程的。但是,在WinForm中,如果我们不刻意使用多线程,那至始至终,都只有一个线程,称之为UI线程。也许在一些小型的系统中WinForm很少涉及到多线程,因为WinForm本身的优势就在它是独立运行在客户端的,在性能上和可操作性上都会有很大的优势。所以很多中小型的WinForm系统都是直接就访问数据库了,并且基本上也只有数据的传输,什么图片资源那是很少的,所以等待的时间是很短的,基本不用费什么脑力去考虑什么3秒之内必须将页面显示到用户面前这种问题。

  既然WinForm在性能上有这么大的优势,那它还需要异步吗?

  我们上面说的是中小型的WinForm,如果是大型的系统呢?如果WinForm只是其它的很小一部分,就像我们文章开始说的还有很多其它成千上万个手机客户端,Web客户端,平板客户端呢?如果客户端很多导致数据库撑不住怎么办? 想在中间加一层缓存怎么办?

  拿一个b2b的网站功能举例,用户可以通过网站下单,手机也可以下单,还可以通过电脑的桌面客户端下单。在下完单之后要完成交易,库存扣减,发送订单确认通知等等功能,而不管你的订单是通过哪个端完成的,这些功能我们都要去做,对吗?那我们就不能单独放在WinForm里面了,不然这些代码在其它的端里面又得全部全新再一一实现,同样的代码放在不同的地方那可是相当危险的,所以就有了我们后来的SOA架构,把这些功能都抽成服务,每种类型的端都是调用服务就可以了。一是可以统一维护这些功能,二是可以很方便的做扩展,去更好的适应功能和架构上的扩展。比如说像下面这样的一个系统。

 图片 10

  在上图中,Web端虽然也是属于我们平常说的服务端(甚至是由多台服务器组成的web群集),但是对我们整个系统来说,它也只是一个端而已。对于一个端来说,它本身只处理和用户交互的问题,其余所有的功能,业务都会交给后来台处理。在我们上面的架构中,应用层都不会直接参加真正业务逻辑相关的处理,而是放到我们更下层数据层去做处理。那么应用层主要协助做一些与用户交互的一些功能,如果手机短信发送,邮件发送等等,并且可以根据优先级选择是放入队列中稍候处理还是直接调用功能服务立即处理。

  在这样的一个系统中,我们的Web服务器也好,Winform端也好都将只是整个系统中的一个终端,它们主要的任何是用户和后面服务之间的一个桥梁。涉及到Service的调用之后,为了给用户良好的用户体验,在WinForm端,我们自然就要考虑异步的问题。 

编辑:独家报道 本文来源:【转】异步编制程序 In .NET

关键词: 转发区【C#】 多线程