本文作者：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一下。我这里说的线程池，不仅仅指由完成端口自己负责维护的那个工作者线程池，还指我们建立在完成端口模型基础之上的线程池。这个线程池里又具体分为执行逻辑线程池和发送线程池。当然，也有人建议执行逻辑线程只要一条就行了，没必要用多条，而且同步会非常麻烦。我赞同这种说法以，但前提是，这样的设计，要求你对服务器功能的划分要相当合理，否则会让这一条线程累得够呛。

　　前面有朋友对本系列文章的题目提出质疑，说：这恐怕不能算是性能优化吧？我要指出的是，本系列文章中提到的优化并不仅仅是某段具体的代码优化，当然这种东西肯定会有，但优化绝不仅仅是这些方面，我这里提到的优化还包括更多的关于模型架构方面的考量。

　　上次我提到，在模型里，引入“池”的概念可以有效改善服务器效率。对于完成端口来说，它处理的是成千上万个的客户端连接。在单一客户端连接的情况下，偶尔的多余操作可能并没有给你的系统带来什么不良影响，但这在形如使用完成端口构建的高性能服务器上是绝对应该避免的，不然，你会发现用了完成端口说不定还没有用其它模型来得高效。另外，需要指出的是，完成端口并不是万能模型，有的地方可以考虑用，而有的地方则完全没必要用，至于完成端口在网游服务器模型里的具体使用，我会在另外的文章里提及。

　　“池”的概念的引入，最主要的是想让服务器在运行时，维护一个相对静态的数据存储空间，并在这个相对静态的空间上进行相关操作。但是，尽管我们千方百计在诸如此类的地方引入“池”，还是不可避免地要遇到这样的几个问题：拼包操作时的数据移动，内存数据的拷贝，socket与客户端对象的一一对应和定位等。下面，将会针对这三方面介绍有关的优化细节。

　　为讨论的方便，在此引入几个状态常量：
　　stAccept：表示处于连接建立状态；
　　stRecv：表示处于数据接收状态；
　　stSend：表示处于数据发送状态。
　　注：本文及后续文章，会简称“GetQueuedCompletionStatus”函数为“Get”函数。

　　现在我们要讨论的是当Get函数返回时，处于stRecv状态时的数据包拼装问题。我们知道，TCP是流协议，它的数据包大小并不一定就是我们期望的发送或接收时的逻辑包大小，每次发送或接收的大小到底是多少，是根据网络的实际状况来决定的。一个在逻辑意义上完整的包，可能会被TCP分为两次进行发送，第一次发送前半部，第二次发送后半部，由此便带来了不完整数据包的拼装问题。那么，要实现数据包的拼装，必须要有一个地方，可以把两个半截的包放到一起，然后从首部根据逻辑包里的大小定义字段取出相应长度的逻辑包。“把两个半截的包放到一起”，这个操作，就涉及到了数据拷贝问题。在实际的应用中，有两种拼装方案可供选择：第一种方案，是将新收到的后半部分数据包复制到前半部分数据包的末尾，形成一个连续的数据包空间，在此空间的基础上进行拼装操作；第二种方案，不用把新收到的后半部分数据包复制到前半部分的末尾，而是在现有两个缓冲区的基础上直接进行拼装操作，当从前半部分搜索到截开的位置时，将指针直接指向新包首部，取走一个完整逻辑意义的包。

　　不论是哪种形式的拼装，可能都会或早或晚地牵涉到剩余数据的拷贝转移问题。第一种方案的情况下，会执行memcpy将新收到的数据包，复制到前半部分数据包的后面；第二种情况，尽管不会首先执行memcpy执行复制，但当执行了“取走所有完整逻辑包”的操作后，缓冲区里可能会残留一个新的不完整的数据包，此时仍需要执行memcpy操作将剩余的这个不完整的数据包复制到原来的前半部分数据包所在的缓冲区，以跟其后续的不完整数据包完成下一步的拼装操作。两种方案的效率，比较起来，第二种方案执行memcpy时所复制的数据内容可能要小得多，所以，相对来说，第二种方案的效率要高一点。

　　当然，如果只就数据包的拼装问题而言，我们也完全可以避免数据拷贝操作，方法就是：使用环形缓冲区。环形缓冲区的实现还是比较简单的，具体的代码我这里不会贴出，只介绍它的基本思想。学过数据结构的人都会知道一种叫作“环形队列”的东西（不知道的，请使用GOOGLE搜索），我们这里所说的环形缓冲区正是具体这种特征的接收缓冲区。在服务器的接收事件里，当我们处理完了一次从缓冲区里取走所有完整逻辑包的操作后，可能会在缓冲区里遗留下来新的不完整包。使用了环形缓冲区后，就可以不将数据重新复制到缓冲区首部以等待后续数据的拼装，可以根据记录下的队列首部和队列尾部指针进行下一次的拼包操作。环形缓冲区，在IOCP的处理中，甚至在其它需要高效率处理数据收发的网络模型的接收事件处理中，是一种应该被广泛采用的优化方案。

　　memcpy函数的优化，在google上可以搜索到相关主题，用的比较多的优化函数是fastmemcpy，本处给出有关memcpy函数优化的两个连接地址：
http://www.blogcn.com/user8/flier_lu/blog/1577430.html
http://www.blogcn.com/user8/flier_lu/blog/1577440.html
请有兴趣的朋友认真阅读一下这两篇文章。优化的核心思想是：根据系统硬件体系架构，来确定最优的数据拷贝方案。根据以上给出的两个连接地址，memcpy会得到较为明显的优化效果。

　　对于网络层来说，每个连接到服务器的客户端唯一标识就是它的socket值，但是，很多情况下，我们需要一个所谓的客户端对象与这个socket能够一一对应，即：以socket值来确定唯一的客户端对象与它对应。于是，我们很自然地会想到使用STL里的map完成这种映射，在实际的使用时，会通过map的查找功能根据socket值取出相应的客户端对象。这样的作法，是较为普遍的作法。但是，尽管map对它的查找算法进行了相应的优化，这个查找也还是要花费一定时间的。如果我们仅仅是要在IOCP的模型里通过GET函数返回时，确定当前返回的socket所代表的那个客户端对象，我们完全可以对投递的overlapped扩展结构进行相应的设置来通过GET函数返回的overlapped扩展结构来直接定位这个客户端对象。

　　我的overlapped结构是这样的：
　　struct  Per_IO_Data {
　　OVERLAPPED  ov;
　　…..
　　CIOCPClient*  iocpClient;
　　…..
　　}
　　大家可以看到，在我的扩展overlapped结构中，我引入了一个客户端对象指针：iocpClient，每次在投递一个WSASend或WSARecv请求时，都会顺带着这个客户端对象指针。这样，当WSASend或WSARecv操作完成时，就可以通过GET函数执行后返回的Per_IO_Data结构取得这个客户端对象指针，从而就省去了根据socket值进行map查找的步骤。在持续的数据收发下，如果在GET函数里频繁地进行map查找，势必会对性能有较大的影响，而通过传递客户端指针到扩展overlapped结构中实现客户端对象的直接定位则大大节省了查找的时间开销，无疑在性能优化方面又作出了一个重大改进。

　　＜未完待续＞