原帖及讨论：http://bbs.bccn.net/thread-110957-1-1.html

1、IOCP(Io Completion Port的缩写)
    当使用并发模型的服务应用程序实现在Windows NT上时，Windows NT小组注意到这些应用程序的性能并没有预料的那么高。特别的，处理很多同时的客户请求意味着很多的线程并发地运行在系统中。因为所有这些线程都是可运行的（没有被挂起和等待发生什么事），Microsoft意识到Windows NT内核花费了太多的时间来转换运行线程的上下文，线程就没有得到很多CPU时间来做他们的工作。
    要使Windows NT成为一个强大的服务器环境，Microsoft就需要解决这个问题。解决的方法是一个称为I/O完成端口的内核对象，它首次在Windows NT3.5中被引入。I/O完成端口的理论基础是并行运行的线程数目必须有一个上限，即有500个同时的客户请求，并不意味着有500个运行的线程。但并发运行的合适的线程是多少呢？读者只要思考一下，就会意识到如果一台机器有两个CPU，那么有多于两个的可运行线埕就没有意义了。一旦可运行的线埕数目超过CPU的数目，系统就不得不花费时间来进行线埕上下文的切换，这将会浪费宝贵的CPU周期。
    并行模型的另一个低效之处是为每一个客户请求创建了一个新线埕。创建线埕比起创建进程来开销要小，但也远不是没有开销。如果当应用程序初始化时创建了一个线埕池，而这些线埕在应用程序执行期间是空闲的，应用程序的性能就能进一步提高。I/O完成端口就使用线埕池。      摘自《Window高级编程指南 第三版》I/O完成端口

2、问题
    很显然，一个网络程序的性能和网卡的能力，网卡驱动的能力，系统的IO能力都有关系

    实验机器大致配置如下：
    A.intel   2.4(单核心)   512M内存   Via   VT6105   网卡  
    B.intel   3.0(双核心)   1G内存       intel   100M网卡   (服务器)  
    C.amd   1800+                   512M内存   81xx网卡  
    
    客户端采用   堵塞IO  
    服务器用   IOCP  
    
    C作为客户端连接A,   建立230个连接,   服务器每秒总共收5500个包,发5500个包，网络占用55%  
    每个包大概1k,这个时候,  
    A机器的CPU   占用达   50%  
    而C的CPU占用<10%  
    
    而完成端口这个时候的表现非常奇怪，不是传说中的scalable  
    在200个连接也就是   3000-4000个包的时候，cpu   <10%  
    后面处理的包增多的时候,cpu占用呈指数上升，很快到   100%  
    
    A一共是2,3个线程,   C一共是231个线程  
    
    如果是这种情况，那连接   <   500的时候   还不如用堵塞模型？      nt系统，对thread的处理很好  
    
    如果一个iocp每秒只能收发5500个包，那么也太少了？


    完成端口==高性能??