nginx现在正在以光的速度蔓延开来，他以其稳定性和高性能等众多优点迅速扩大市场，大家都知道，nginx是以单线程为基础的，那么他怎么能在并发性上取得优势的呢？会不会因为网络阻塞而导致主线程阻塞呢？下面就相关问题作一些概念性的阐述。
这篇文章写得好还有代码从自己角度来说nginx的epoll架构，AddTime：2015-02-03
http://blog.csdn.net/zhaoxy_thu/article/details/24624729
问题的根本在于人们对于计算机处理性能还没有足够的认识，以及普通的服务器架构简化的处理，做过大型的成熟服务器的人可能都知道，解决一个系统瓶颈比优化1000个算法还重要，这也就是木桶效应，一个桶能盛水的多少决定于最短的那一块板，我们之所以在一般的服务器端应用软件中采用一个连接一个线程甚至阻塞在一个线程上的做法，并不是这个方法是最优秀的，设计者没有更好的方法，而是因为这种套路是最简单的，在概念上以及操作上都比较容易让人理解，并且容错性也强，但是对于性能要求极高的服务器比如dns或者负载均衡等等，要求处理速度极快，并且能有较高的并发性，这种简单的线程池加连接池的做法就不能解决问题了，比如一个index页面请求，他会包含几十个附属资源文件，如果cilent网络比较慢，那么就会较长时间的阻塞这几十个连接，用户稍微一多服务器就受不了，因为线程的开销是很大的，如果不能得到迅速释放，将会给服务器带来灾难性的后果，对于公网服务，这种之后会尤为明显，很显然，让服务器为客户端的网速买单是愚蠢的做法。
那么既然多线程都会存在这样的问题单线程怎么会逃脱的调呢？解决问题的关键在于异步IO，windows上有IOCP（完成端口，对于一部IO包装的比较多，内部实现时用cpu个数的线程进行事件处理，他会通知你你给定的异步读写已经完成了），linux上有epool(一个纯事件通知接口，他会通知你可以读或者可以写了)，如果将所有的请求简化为阻塞操作和非阻塞操作问题就简单了，所有需要阻塞请求的部分全部由epool触发相应事件，非阻塞（处理耗时很短）部分用主线程一直执行，直到遇到阻塞部分就停止，交由阻塞部分监听异步完成事件，这样就构成了事件驱动模型。
这里比较容易迷惑人的地方是很多人认为函数的处理会阻塞主线程，其实还是上面说的木桶效应，他是不是那块最短的木板，这是需要由测试和经验来决定的，事实是他的处理时间占用很短，做100万次for循环说不定比局域网经过一次网络访问的时间还要短，理解了这点就不难理解了，如果说你的服务器每秒钟能处理1万个请求，那么在处理功能函数上（比如解析协议，操作、输出等等）顶多也就占用0.1-0.3秒，剩下的时间都是耗时在了网络阻塞上，耗时在了事件发生上了，既然如此，把操作部分独立分出来用多线程执行又有什么意义呢？对于公网就更不用说了，网络等IO阻塞才是影响服务器的主要因素，是那块短了的板。
对于网络的IO，IOCP 、epool等事件通知机制就解决了这个问题，性能上由于是阻塞的，所以还不如直接accept等快，但是对于网络延时很严重的情况下性能反而显得更好，因为他们可以处理大量的连接而不使性能下降很厉害，如果值直接阻塞能连接处理1000个的话，epool等就可以同时处理3-5万个，所以实际的应用价值要大得多。
剩下的部分就是处理事件发生后的事情上面，我前面的文章已经作了说明，在此不再重复，nginx 、lighttpd等都是基于这类模型开发的，有兴趣的可以研究一下他的代码。
来源：http://hi.baidu.com/netpet/blog/item/ccaf84d4746de307a08bb731.html
这篇文章写得好还有代码从自己角度来说nginx的epoll架构，AddTime：2015-02-03
http://blog.csdn.net/zhaoxy_thu/article/details/24624729
问题的根本在于人们对于计算机处理性能还没有足够的认识，以及普通的服务器架构简化的处理，做过大型的成熟服务器的人可能都知道，解决一个系统瓶颈比优化1000个算法还重要，这也就是木桶效应，一个桶能盛水的多少决定于最短的那一块板，我们之所以在一般的服务器端应用软件中采用一个连接一个线程甚至阻塞在一个线程上的做法，并不是这个方法是最优秀的，设计者没有更好的方法，而是因为这种套路是最简单的，在概念上以及操作上都比较容易让人理解，并且容错性也强，但是对于性能要求极高的服务器比如dns或者负载均衡等等，要求处理速度极快，并且能有较高的并发性，这种简单的线程池加连接池的做法就不能解决问题了，比如一个index页面请求，他会包含几十个附属资源文件，如果cilent网络比较慢，那么就会较长时间的阻塞这几十个连接，用户稍微一多服务器就受不了，因为线程的开销是很大的，如果不能得到迅速释放，将会给服务器带来灾难性的后果，对于公网服务，这种之后会尤为明显，很显然，让服务器为客户端的网速买单是愚蠢的做法。
那么既然多线程都会存在这样的问题单线程怎么会逃脱的调呢？解决问题的关键在于异步IO，windows上有IOCP（完成端口，对于一部IO包装的比较多，内部实现时用cpu个数的线程进行事件处理，他会通知你你给定的异步读写已经完成了），linux上有epool(一个纯事件通知接口，他会通知你可以读或者可以写了)，如果将所有的请求简化为阻塞操作和非阻塞操作问题就简单了，所有需要阻塞请求的部分全部由epool触发相应事件，非阻塞（处理耗时很短）部分用主线程一直执行，直到遇到阻塞部分就停止，交由阻塞部分监听异步完成事件，这样就构成了事件驱动模型。
这里比较容易迷惑人的地方是很多人认为函数的处理会阻塞主线程，其实还是上面说的木桶效应，他是不是那块最短的木板，这是需要由测试和经验来决定的，事实是他的处理时间占用很短，做100万次for循环说不定比局域网经过一次网络访问的时间还要短，理解了这点就不难理解了，如果说你的服务器每秒钟能处理1万个请求，那么在处理功能函数上（比如解析协议，操作、输出等等）顶多也就占用0.1-0.3秒，剩下的时间都是耗时在了网络阻塞上，耗时在了事件发生上了，既然如此，把操作部分独立分出来用多线程执行又有什么意义呢？对于公网就更不用说了，网络等IO阻塞才是影响服务器的主要因素，是那块短了的板。
对于网络的IO，IOCP 、epool等事件通知机制就解决了这个问题，性能上由于是阻塞的，所以还不如直接accept等快，但是对于网络延时很严重的情况下性能反而显得更好，因为他们可以处理大量的连接而不使性能下降很厉害，如果值直接阻塞能连接处理1000个的话，epool等就可以同时处理3-5万个，所以实际的应用价值要大得多。
剩下的部分就是处理事件发生后的事情上面，我前面的文章已经作了说明，在此不再重复，nginx 、lighttpd等都是基于这类模型开发的，有兴趣的可以研究一下他的代码。
来源：http://hi.baidu.com/netpet/blog/item/ccaf84d4746de307a08bb731.html
作者：jackxiang@向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除
地址：http://jackxiang.com/post/3878/
版权所有。转载时必须以链接形式注明作者和原始出处及本声明！
最后编辑： jackxiang 编辑于2015-2-3 16:15
启迪人心：10个的有关编程的至理名言
异步IO、APC、IO完成端口、线程池与高性能服务器之一 异步IO评论列表
