usercount

聊聊IOCP,聊聊异步编程

前言

IO完成端口(IO completion ports)在多核计算机的并行异步IO请求方面提供了一种高效的线程模型。当进程创建一个IO完成端口时,系统创建一个相关联的队列,其唯一目的是服务与那些请求。IO完成端口通常和预先分配的线程池配合,相比于一个一个创建线程,这使其更快更高效。IOCP在进程之间并不共享,一个IOCP及其句柄只和创建它的进程关联,但是一个进程中的多个线程可共享。IOCP最关键的地方就是,IOCP在IO请求和接收动作完成之后,激活线程池中的任意线程继续操作,而不是在IO请求和接受完成之后,激活原等待中的线程。这样的好处是防止等待线程闲置,和必须激活/切换到原等待线程的开销。

 

大多应用存在的问题

曾见过很多服务,几台,几十台,几百台服务器的,它们cpu大多数时间处于空闲状态,也许需要大量计算的应用并没有那么多,我们常见的应用大多主要读写关系数据库,读写内存数据库/缓存,RPC调用接口。IO耗时过多,CPU大量闲置,导致没看到服务器资源大量消耗,便已不能承受日益增加的访问量,再加服务器,依然大量浪费了资源。 CPU资源昂贵,每一个核心,同一时刻只能有一个线程在运行,超线程cpu同一时刻可以有两个逻辑线程运行,所以说线程不是创建的越多越好,过多的线程只会增加线程切换带来的成本。试想一下,如果应用线程池的线程,都在同步等待IO操作的结束,线程池中也就没有空闲线程继续处理请求,所以线程池会继续创建线程以提供服务。恶性循环,则会带来线程过多的成本,好在线程池不会让这样的事发生。那么到达服务器无法处理更多请求的程度时,http 503便出现了。

 

windows下使用IOCP

异步IO在于线程非阻塞,提高CPU利用率,增加服务器吞吐量,助我们承受更大的并发。在windows下使用IOCP,可以直接使用C#异步编程await/async。虽然C#可以直接操作win32API,但.NET平台已提供好异步IO的操作封装,只需要简单的语法,即可完成异步磁盘IO,异步HTTP请求,异步SOCKET,基于.NET框架现有的条件,也很容易做关系数据库,redis,ElasticSearch,mongodb的异步读写。所以推荐在windows下的IO尽可能使用IOCP。IOCP本质上解决的问题就是CPU和IO速度极大的不对等。

 

基于IOCP的异步编程线程行为证明

简单写了个API接口,用于证明在异步IO操作的时候,线程并不阻塞等待IO结束,而是将请求交给驱动后返回线程池,继续工作。

图中代码操作是先记录当前请求处理中的线程ID,然后请求一个10s返回的网络接口。用http客户端并发请求图中该接口后,我们稍后给出线程行为的结论。 我们都知道,如果说服务端线程是IO阻塞的,第一次请求,如果记录了线程ID为1,那么在10s内,该线程一直在阻塞等待,所以10s内不会再出现该线程ID被记录到日志中。 事实上结论是:

可以看到在同一秒甚至同一毫秒内,一个线程同时处理了多次http请求。另外可以确定的一个事实是,IO前和IO后,线程可能是不一样的,也可能是一样的。

 

感谢志同道合的你的阅读,如果你希望长期学习到 .Net , Java , Kotlin ,Python 等原理知识,互联网实践干货,技术感悟等,不妨 关注博客,或者闲暇时在微信公众号上阅读。

 

 

 

posted @ 2018-09-04 00:51 坦荡 阅读(...) 评论(...) 编辑 收藏