本文作者：sodme 本文出处：http://blog.csdn.net/sodme
版权声明：本文可以不经作者同意任意转载，但转载时烦请保留文章开始前两行的版权、作者及出处信息。
完成端口的主要优点在哪里？
完成端口的最大优点在于其管理海量连接时的处理效率，通过操作系统内核的相关机制完成IO处理的高效率。注意：完成端口的优点在于管理连接量的巨大，而不是传输数据量的巨大。在这种场合最适合用完成端口：连接量巨大，且每个连接上收发的数据包容易比较小，通常只有几K甚至不到1K的字节。
既然完成端口处理的是海量连接问题，那么我们对完成端口的优化则也应该首先放在海量连接的相关管理上。为此，我们引入“池”的概念。
在完成端口的设计中，“池”几乎是必须采用的原则。这里的“池”包含有多个方面，分为：线程池，内存池，连接池等等。下面，将逐一介绍这些“池”的含义及用途，稍后的文章里，如果可能的话，我会给出采用了“池”和未采用“池”两种情况下的效率对比，你将会发现“池”是多么地可爱。
在大型在线系统中，数据空间的频繁创建和释放是相当占用系统资源的。为此，在数据空间的管理上，我们引入了“内存池”。
大家知道，在每一次的wsasend和wsarecv中，我们都要投递一个结构体变量。这个结构体变量的创建和释放，可以有多种方式。
方式一：即用即创建，即每次执行wsasend和wsarecv时都声明一个新的结构体空间，GET完成后在工作者线程中销毁；
方式二：只有每出现一个新的连接时，我们才随新连接建立一个新的结构体空间，将它与新的客户端socket绑定在一起，只有当客户端socket关闭时才将它与客户端对象一起销毁；
方式三：建立一定量的结构体空间，并将其统一放入一个空闲队列，不管何时执行wsasend和wsarecv，都先从空闲队列里取一个结构体空间来用，用完后，将其放回空闲队列。
从执行的效率及实现的便捷性方面考虑，建议采用方式3的形式管理这些空闲结构体空间。采用方式3的难点在于，到底创建多少个结构体空间才是比较合适的？这可能取决于你在自己服务器上作的完成端口的处理效率，如果完成端口的处理效率比较高，那么需要的队列长度可能就比较小，如果完成端口的处理效率低，那么队列长度就要大一点。
下面说说“连接池”。我们知道，使用传统的accept接收客户端的一个连接后，此函数会返回一个创建成功的客户端socket，也就是说，此函数自己完成了socket的创建工作。非常好的是，windows给我们提供了另一个函数，允许我们在接受连接之前就事先创建一个socket，使之于接受的连接相关联，这个函数就是acceptEx，在acceptEx的参数中，SOCKET类型的参数值是我们事先用socket函数创建完成的一个socket，在调用acceptEx时，把这个已经创建好的socket传给acceptEx。说到这里，明白的人可能已经偷笑了－－既然这样，那岂不是允许我们在接受连接之前就创建好一大堆的socket等着acceptEx来用吗？这就省去了临时创建一个socket的系统开销呀？呵呵，事实确实如此。在实际操作中，我们可以事先创建好一大堆的socket，然后接受客户端连接的函数使用acceptEx。这一大堆的socket，我们可以形象地称之为“socket连接池”（当然，也许在更多的场合，我们听到的是“数据库连接池”的概念），这个名字是我自己取的，听着觉得不舒服的兄弟，干脆就叫它“socket池”吧，哈哈。
线程池的概念，相信作过多线程的朋友都会有所耳闻。在此处的文字中，就不对它再多加介绍了，感兴趣的朋友可以自己去GOOGLE一下。我这里说的线程池，不仅仅指由完成端口自己负责维护的那个工作者线程池，还指我们建立在完成端口模型基础之上的线程池。这个线程池里又具体分为执行逻辑线程池和发送线程池。当然，也有人建议执行逻辑线程只要一条就行了，没必要用多条，而且同步会非常麻烦。我赞同这种说法以，但前提是，这样的设计，要求你对服务器功能的划分要相当合理，否则会让这一条线程累得够呛。
未完待续
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/sodme/archive/2005/04/14/348133.aspx