完成端口，到底一个CPU 建几个线程

接下来看看完成端口（Completion Ports ）

其实可以把完成端口看成系统维护的一个队列，操作系统把重叠IO操作完成的事件通知放到该队列里，由于是暴露 “操作完成”的事件通知，所以命名为“完成端口”（Completion Ports）。一个socket被创建后，可以在任何时刻和一个完成端口联系起来。

一般来说，一个应用程序可以创建多个工作线程来处理完成端口上的通知事件。工作线程的数量依赖于程序的具体需要。但是在理想的情况下，应该对应一个CPU创建一个线程。因为在完成端口理想模型中，每个线程都可以从系统获得一个“原子”性的时间片，轮番运行并检查完成端口，线程的切换是额外的开销。在实际开发的时候，还要考虑这些线程是否牵涉到其他堵塞操作的情况。如果某线程进行堵塞操作，系统则将其挂起，让别的线程获得运行时间。因此，如果有这样的情况，可以多创建几个线程来尽量利用时间。

总之，开发一个可扩展的Winsock服务器并非十分困难的。主要是开始一个监听socket,接收连接，并且进行重叠发送和接收的IO操作。最大的挑战就是管理系统资源，限制重叠Io的数量，避免内存危机。遵循这几个原则，就能帮助你开发高性能，可扩展的服务程序。

socket的接收缓冲，因为接收事件仅仅在AcceptEx调用中发生。保证每个socket都有一个接收缓冲不会造成什么危害。一旦客户端/服务器在最初的一次请求（由AcceptEx完成）之后进行交互，发送更多的数据，那么取消接收缓冲更是一个很不好的做法。除非你能保证这些数据都是在每个连接的重叠IO接收里完成的 。

向左转|向右转

一个老生常谈的问题，本以为网上能搜索到很满意的答案，但结果很不尽人意，于是自己写下测试程序，好好测试下；

测试用例

服务器、客户端都在一台电脑上，服务器采用IOCP，客户端普通的socket，创建、连接、发送、接收，但不关闭，循环100000次，每次SLEEP（1），

测试环境：WIN XP 32

客户端在第13400左右次连接服务器失败；关闭客户端联系做了50次类似测试，服务器内存在10多M,慢慢增加至100M左右内存时，内存自动回收，按每次客户端连接成功4000次计算，可以连接成功20w次。（昨天测试结果，未完待续。。。）

测试环境：WIN SERVER 2003 64

单一客户端（64）在44449次时连接失败，同时启动2个客户端，分别在3w多次连接失败。

使用api函数 WSAGETSELECTEVENT()函数接受管理socket，当接受到请求时使用gethostbyname

如：swich（WSAGETSELECTEVENT(socket)）

CASE FD_ACCEPT: gethostbyname

WSAGETSELECTEVENT()是实现非阻塞编程的关键

HTTP Server API Version 20 Reference (Windows)

读完这个你就懂了，就那么几个函数，自动使用IOCP和httpsys，根本无需担心性能问题，只要写你的业务逻辑就好了。

msdn还有良心sample：HTTP Server Sample Application (Windows)

主要实现

插件通过$post实现与服务器的交互主要用于实现浏览器任务 控制

1：客户端发送post请求 wait请求 用于连接服务器，

2：服务器接收wait请求 并处理 发送一个响应

3：客户端接收服务器处理的wait请求后数据 并处理 处理后发送一个$post用于跟踪 或 继续处理(客户端发出的请求可能存在回调，或不存在回调， 不存在回调的情况 服务器只能从wait请求中 来和客户端交互)

现在我用iocp 做了一个服务器， 为什么服务器接收一个wait请求后 处理 发送一个处理后的响应 而客户端 再也没有wait请求过来了 这是什么情况？ 这个问题应该出现在服务器的响应， 客户端的请求代码如下：

//发送ajax请求

$post(server_url, {"soft_version":soft_ver,"reqname":"wait", "WinId":winId}, success, "json")fail(fail);

function fail() {

srv_connected = false;

setTimeout(function(){

$post(server_url,{"soft_version":soft_ver,"reqname":"wait","WinId":winId}, success, "json")fail(fail);

}, 2000);

}

//成功后的回调

function success(msg) {

//用于等待 获取客户端的数据

setTimeout(function(){

$post(server_url,{"soft_version":soft_ver,"reqname":"wait","WinId":winId}, success, "json")fail(fail);

}, 200);

if(msg == null || msgcmd == null){

return;

}

//处理

}

服务器的响应

HTTP/11 200 OK

Content-Type: text/html; charset=UTF-8

Server: HTTP20/Fuck-TB

Content-Length: 111

　　首先，必须承认的一点是，IOCP，EPOOL以及KQUEUE在本质上并没有太大的区别，对于成熟的商业公司和全球性的开源组织来说其最终实现的效率不会有太大的区别。这一点是讨论的基础，狂热的anti ms分子狂扁windows一无是处的说法不足以作为论据，当然一说windows哪里不足就仿佛被抓住痛脚立马反击也是不可取的。

　　第二点，抛开应用服务器的性能差异，ASPNET还是java，什么的，暂时抛开，一般来说，借用绝世好bra的台词，在应用服务器down掉前，一般web服务器是不会down的。所以web服务器的处理能力应该远远高于应用服务器。那么现在纯粹对比的就是对静态文件的处理能力了。

　　对静态文件的处理能力，大文件处理的性能对比是没有意义的，大文件传输考察的带宽而不是服务器性能。所以要对比的就是对小文件的并发处理能力，由于在网络层面的优劣并不明显，所以最终影响结果的就是文件系统的优劣了，这也是打消进行测试的主要原因：linux下可以选择的文件系统有好几个，挨个测试的假期就泡汤了。

　　现在条理已经理清楚了，那么测试其实就是在对比NTFS和linux下可用的ext3,ext4,Reiserfs等文件系统性能，其实这也是IIS和Nginx对比测试结果各异的由来，而linux的影响因素太多了，内核网络参数调优，文件系统等都能够左右测试的结果。

　　不过在常规情况下，未经过特别调优作为前提来考量的话，linux下nginx的性能是超过IIS的，因为linux从某种意义上来说，是一种文件型的操作系统，连设备都是挂载到一个文件符号，当做一个文件来处理，其本身在处理文件的能力上是超过windows的。