这段时间其实有不少人在关注nginx线程池的功能，我也跟同事聊了下。

英文版

http://nginx.com/blog/thread-pools-boost-performance-9x/

中文版

http://www.infoq.com/cn/articles/thread-pools-boost-performance-9x

对于nginx在1.7.1版本之后加入线程池的这个future， 看了好几遍infoq的那篇文章，里面介绍了如何利用nginx 线程池实现9倍的性能…. 个人看了下，他核心的概念就是把你认为堵塞的io模块扔到线程池里面，然后去worker去接受新的任务，当有结果的时候，在从线程池里面取结果，然后返回。。。

     linux系统本身就对于文件系统的异步io支持是有限的，在nginx加入线程池的功能，我个人觉得提升不大，毕竟你就算承接了更多的客户端的请求，但是你最后返回数据的逻辑，还是在堵塞中…  毕竟磁盘io的能力是有限的，当然如果你的磁盘io很强，比如ssd，那就另说了….    这只是个人的理解，如有不对的地方，请大家喷下….. 在就是线程池现在只能是用在文件的读写上。

标记下文章的原文  http://xiaorui.cc/?p=1681

做过运维的人知道，一般来说从单台nginx到集群扩展的变化，就是看单台nginx的网卡是否快了，或者是磁盘的io快爆了….   倒是少见那种nginx磁盘和网络怎么都跑不满的状况。 

这是章亦春在google groups的回复…  有个人问了关于nginx线程池性能的疑问 

https://groups.google.com/forum/#!topic/openresty/_0EuIRFrc7E

今天看了一下网上的一篇文章
http://nginx.com/blog/thread-pools-boost-performance-9x/
说道把重阻塞型计算通过线程来完成，能很好的解除对nginx worker事件循环的干扰，我想起以前我想用nginx workder来播放mp3，结果不能发声，应该是解码库和nginx worker不相融的缘故吧？
如果能把播放任务交由线程池来完成，这样nginx就起到了beanstalkd的作用，不知将来是否会考虑在ngx_lua中提供一个在线程池中创建task的API，这样openresty就扮演了work queue的角色，这样妈妈再也不用担心通过cosokect去连接的另一个队列服务器挂了的痛苦了。
— 
with kind regards
 

agentzh
6月19日

Hello! 

2015-06-19 15:29 GMT+08:00 Zheng Ping: 
> 
> 今天看了一下网上的一篇文章 
> http://nginx.com/blog/thread-pools-boost-performance-9x/ 
> 说道把重阻塞型计算通过线程来完成，能很好的解除对nginx worker事件循环的干扰， 

nginx 的这个 OS 线程池主要为了规避 disk I/O 的阻塞效应（毕竟不存在 nonblocking disk I/O 
这种东西，而 AIO 又有很多问题）。nginx 的创始人 Igor Sysoev 在去年和我见面时也亲口这么说的。 

这个东西的引入其实并不是为了 CPU 密集型的东西。对于 CPU 密集型的东西，更多的 OS 线程可以让请求之间更加公平，但同时因为 CPU 
争用的开销，系统的整体吞吐量会下降。毕竟当前系统的 CPU 资源是一个常数，并不会因为你创建的 OS 
线程越多就凭空增加出来，相反，只会因为线程本身的开销而浪费一些。 

建议仔细追踪来确认问题，而最好不要猜测归因 :) 

其实跟我的初步的想法是差不多的。 看样子章亦春对于nginx引入线程池后能提高9倍的性能的说法，还是有些不确定性的…..   

---

大家觉得文章对你有些作用！ 如果想赏钱，可以用微信扫描下面的二维码，感谢!
另外再次标注博客原地址  xiaorui.cc