前面有朋友對本系列文章的題目提出質疑，說：這恐怕不能算是效能優化吧？我要指出的是，本系列文章中提到的優化並不僅僅是某段具體的**優化，當然這種東西肯定會有，但優化絕不僅僅是這些方面，我這裡提到的優化還包括更多的關於模型架構方面的考量。
上次我提到，在模型裡，引入「池」的概念可以有效改善伺服器效率。對於完成埠來說，它處理的是成千上萬個的客戶端連線。在單一客戶端連線的情況下，偶爾的多餘操作可能並沒有給你的系統帶來什麼不良影響，但這在形如使用完成埠構建的高效能伺服器上是絕對應該避免的，不然，你會發現用了完成埠說不定還沒有用其它模型來得高效。另外，需要指出的是，完成埠並不是萬能模型，有的地方可以考慮用，而有的地方則完全沒必要用，至於完成埠在網遊伺服器模型裡的具體使用，我會在另外的文章裡提及。
「池」的概念的引入，最主要的是想讓伺服器在執行時，維護乙個相對靜態的資料儲存空間，並在這個相對靜態的空間上進行相關操作。但是，儘管我們千方百計在諸如此類的地方引入「池」，還是不可避免地要遇到這樣的幾個問題：拼包操作時的資料移動，記憶體資料的拷貝，socket與客戶端物件的一一對應和定位等。下面，將會針對這三方面介紹有關的優化細節。
為討論的方便，在此引入幾個狀態常量：
staccept：表示處於連線建立狀態；
strecv：表示處於資料接收狀態；
stsend：表示處於資料傳送狀態。
注：本文及後續文章，會簡稱「getqueuedcompletionstatus」函式為「get」函式。
完成埠之效能優化 2
前面有朋友對本系列文章的題目提出質疑，說 這恐怕不能算是效能優化吧？我要指出的是，本系列文章中提到的優化並不僅僅是某段具體的 優化，當然這種東西肯定會有，但優化絕不僅僅是這些方面，我這裡提到的優化還包括更多的關於模型架構方面的考量。上次我提到，在模型裡，引入 池 的概念可以有效改善伺服器效率。對於完...
完成埠之效能優化 1
方式二 只有每出現乙個新的連線時，我們才隨新連線建立乙個新的結構體空間，將它與新的客戶端socket繫結在一起，只有當客戶端socket關閉時才將它與客戶端物件一起銷毀 方式三 建立一定量的結構體空間，並將其統一放入乙個空閒佇列，不管何時執行wsasend和wsarecv，都先從空閒佇列裡取乙個結構...
完成埠之效能優化 1
方式二 只有每出現乙個新的連線時，我們才隨新連線建立乙個新的結構體空間，將它與新的客戶端socket繫結在一起，只有當客戶端socket關閉時才將它與客戶端物件一起銷毀 方式三 建立一定量的結構體空間，並將其統一放入乙個空閒佇列，不管何時執行wsasend和wsarecv，都先從空閒佇列裡取乙個結構...