重疊I/O模型的另外幾個優點在於，微軟針對重疊I/O模型提供了一些特有的擴展函數。當使用重疊I/O模型時，可以選擇使用不同的完成通知方式。
採用事件對象通知的重疊I/O模型是不可伸縮的，因爲針對發出WSAWaitForMultipleEvents調用的每個線程，該I/O模型一次最多都只能支持6 4個套接字。假如想讓這個模型同時管理不止64個套接字，必須創建額外的工作者線程，以便等待更多的事件對象。因爲操作系統同時能夠處理的事件對象是有限的，所以基於事件對象的I/O模型不具備伸縮性。
使用完成例程通知的重疊I/O模型，因爲以下幾個原因，也不是開發高性能服務器的最佳選擇。首先，許多擴展功能不允許使用APC（Asyncroneus Procedure Call，異步過程調用）完成通知。其次，由於APC在系統內部特有的處理機制，應用程序線程可能無限等待而得不到完成通知。當一個線程處於“可警告狀態”時，所有掛起的APC按照先進先出的順序（FIFO）接受處理。現在考慮這樣一種情況，服務器已經建立起了一個連接，並且調用含有完成例程指針的WSARecv投遞了一個重疊I/O請求。當有數據到達時（即I/O完成時），完成例程執行並且再次調用WSARecv拋出另外一個重疊I/O請求。一個APC拋出的I/O操作需要一定的時間才能完成，所以這期間可能另外一個完成例程等待執行（比如本次WSARecv還沒接收完時，又有一個新的客戶接入併發來數據），因爲還有更多的數據需要讀取（上一個客戶發來的數據尚未讀完）。只要（投遞WSARecv的）那個套接字上還有“未決”（未接收完）的數據，就會導致調用線程長久阻塞。
基於完成端口通知的重疊I/O模型是Windows NT系統提供的一個真正支持高伸縮性的I/O模型。在上一章中，探討了Winsock幾種常見的I/O模型，並且說明了當應對大規模客戶連接時，完成端口是最佳的選擇，因爲它提供了最好的伸縮性。
對不同Winsock I/O模型的性能測試結果如圖1所示。其中服務器採用Pentium 4 1.7 GHz Xeon的CPU，768M內存；客戶端有3臺PC，配置分別是Pentium 2 233MHz ，128 MB 內存，Pentium 2 350 MHz ，128 MB內存，Itanium 733 MHz ，1 GB內存。服務器、客戶端安裝的操作系統都是Windows XP。
圖1 不同I/O模型的性能比較
1.分析圖表1提供的測試結果可知，在所用的I/O模型中，阻塞模式性能最差。這個測試程序中，服務器爲每個客戶創建兩個線程：一個負責處理數據的接收，一個負責處理數據的發送。在多次測試中的共同問題就是，阻塞模式難以應對大規模的客戶連接，因爲它在創建線程上耗費了太多的系統資源。因此，服務器創建太多的線程後，再調用CreateThread函數時，將返回ERROR_NOT_ENOUGH_MEMORY的錯誤，這個錯誤碼提示內存不夠。那些發出連接請求的客戶則收到WSAECONNREFUSED的錯誤提示，表示連接的嘗試被拒絕。
讓我們來看看監聽函數listen，其原型如下：
WINSOCK_API_LINKAGE int WSAAPI listen（SOCKET s, int backlog ）;
參數一s已綁定了地址的監聽套接字。
參數二backlog指定了正在等待連接的最大隊列長度。
參數backdog非常重要, 因爲完全可能同時出現幾個對服務器的連接請求。例如，假定backlog參數爲2時有三個客戶機同時發出連接請求，那麼前兩個會被放在一個“等待處理”隊列中，以便應用程序依次爲它們提供服務。而第三個連接的請求就會造成一個WSAECONNREFUSED錯誤。一旦服務器接受了一個連接請求，那個連接請求就會從隊列中刪去，以便可以繼續接收其他客戶發出的連接請求。即當一個連接請求到來時隊列已滿，那麼客戶將收到一個WSAECONNREFUSED錯誤。而backlog參數本身的大小就存在着限制，這個限制是由協議提供者決定的。
故阻塞模式下，由於系統資源的限制，其併發處理量是極難突破的。
2.非阻塞模式表現出的性能要比阻塞模式稍好，但是佔用了太多的CPU處理時間。測試服務器將所有客戶對應的socket分類放到FD_SET集合中，然後調用select函數篩選出對應集合中有事件發生的socket，並對集合更新。接下來調用FD_ISSET宏重新判斷一個套接字是否在原來加入的FD_SET集合中。隨着客戶連接數量的增多，這種模型的侷限性逐漸凸現。僅僅爲了判斷一個套接字是否有網絡事件發生，就需要對集合FD_SET執行一次遍歷!使用迭代搜索來對select更新的FD_SET進行掃描，性能可以得到一些提升。瓶頸在於，服務器必須能夠很快地掃描出FD_SET集合中的有網絡事件發生的套接字的相關信息。針對這個問題，可以使用更復雜的掃描算法，如哈希搜索，它的效率是極高的。還需要注意的一個問題就是，非分頁池（即直接在物理內存中分配的內存）的使用極高。這是因爲AFD（Ancillary
Function Driver,由afd.sys提供的支持Windows Sockets應用程序的底層驅動程序，其中運行在內核模式下afd.sys驅動程序主要管理Winsock TCP/IP通信）和TCP都將使用I/O緩存，因爲服務器讀取數據的速度是有限的，相對於CPU的處理速度而言，I/O基本是零字節的吞吐量。
3.基於Windows消息機制的WSAAsyncSelect模型能夠處理一定的客戶連接量，但是擴展性也不是很好。因爲消息泵很快就會阻塞，降低了消息處理的速度。在幾次測試中，服務器只能處理大約1/3的客戶端連接。過多的客戶端連接請求都將返回錯誤提示碼WSAECONNREFUSED，說明服務器不能及時處理FD_ACCEPT消息導致連接失敗，這樣監聽隊列中待處理的連接請求不致於爆滿。然而，通過上表中的數據可以發現，對那些已經建立的連接，其平均吞吐量也是極低的（即使對於那些對比特率進行了限制的客戶也如此）。
4.基於事件通知的WSAEventSelect模型表現得出奇的不錯。在所有的測試中，大多數時候，服務器基本能夠處理所有的客戶連接，並且保持着較高的數據吞吐量。這種模型的缺點是，每當有一個新連接時，需要動態管理線程池，因爲每個線程只能夠等待64個事件對象。當客戶連接量超過64個後再有新客戶接入時，需要創建新的線程。在最後一次測試中，建立起了超過45,000個的客戶連接後，系統響應速度變得非常緩慢。這時由於爲處理大規模的客戶連接創建了大量的線程，佔用了過多的系統資源。791個線程基本達到了極限，服務器不能再接受更多的連接了，原因是WSAENOBUFS：無可用的緩衝區空間，套接字無法創建。另外，客戶端程序也達到了極限，不能維持已經建立的連接。
使用事件通知的重疊I/O模型和WSAEventSelect模型在伸縮性上差不多。這兩種模型都依賴於等待事件通知的線程池，處理客戶通信時，大量線程上下文的切換是它們共同的制約因素。重疊I/O模型和WSAEventSelect模型的測試結果很相似，都表現得不錯，直到線程數量超過極限。
5.最後是針對基於完成端口通知的重疊I/O模型的性能測試，由上表中數據可以看出，它是所有I/O模型中性能最佳的。內存使用率（包括用戶分頁池和非分頁池）和支持的客戶連接量與基於事件通知的重疊I/O模型和WSAEventSelect模型基本相同。真正不同的地方，在於對CPU的佔用。完成端口模型只佔用了60%的CPU，但是在維持同樣規模的連接量時，另外兩種模型（基於事件通知的重疊I/O模型和WSAEventSelect模型）佔用更多的CPU。完成端口的另外一個明顯的優勢是，它維持更大的吞吐量。
對以上各種模型進行分析後，可以會發現客戶端與服務器數據通信機制本身存在的缺陷是一個瓶頸。在以上測試中，服務器被設計成只做簡單的迴應，即只是將客戶端發送過來的數據發送回去。客戶端（即使有比特率限制）不停的發送數據給服務器，這導致大量數據阻塞在服務器上與這個客戶端對應的套接字上（無論是TCP緩衝區還是AFD的單套接字緩衝區，它們都是在非分頁池上）。在最後三種性能比較好的模型中，同一時間只能執行一個接受輸入操作，這意味着在大多數時間，還是有很多數據處於“未決”狀態。可以修改服務器程序使其以異步方式接受數據，這樣一旦有數據達到，需要將數據緩存起來。這種方案的缺點是，當一個客戶連續發送數據時，異步接受到了大量的數據。這會導致其他的客戶無法接入，因爲調用線程和工作者線程都不能處理其他的事件或完成通知。通常情況下，調用非阻塞異步接收函數，先返回WSAEWOULDBLOCK，然後數據間斷性的傳輸，而不採取連續接收的方式。
從以上測試結果，可以看出WSAEventSelect模型和重疊I/O模型是性能表現最佳的。兩種基於事件通知的模型中，創建線程池來等待事件完成通知並作後續處理是很繁瑣的，但是並不影響以它們來架構中型服務器的良好性能。當線程的數量隨着客戶端連接數量而逐增時，CPU將花費大量時間在線程的上下文切換上，這將影響服務器的伸縮性，因爲連接量達到一定數量後，便飽和了。完成端口模型提供了最佳的可擴展性，因爲CPU使用率低，其支持的客戶連接量相對其他模型最多。
I/O模型的選擇
通過上一節對各種模型的測試分析，對於如何挑選最適合自己應用程序的I/O模型已經很明晰了。同開發一個簡單的運行多線程的鎖定模式應用相比，其他每種I/O模型都需要更爲複雜的編程工作。因此，針對客戶機和服務器應用開發模型的選擇，有以下原則。
1. 客戶端
若打算開發一個客戶機應用，令其同時管理一個或多個套接字，那麼建議採用重疊I/O或WSAEventSelect模型，以便在一定程度上提升性能。然而，假如開發的是一個以Windows爲基礎的應用程序，要進行窗口消息的管理，那麼WSAAsyncSelect模型恐怕是一種最好的選擇，因爲WSAAsyncSelect本身便是從Windows消息模型借鑑來的。採用這種模型，程序需具備消息處理功能。
2. 服務器端
若開發的是一個服務器應用，要在一個給定的時間，同時控制多個套接字，建議採用重疊I/O模型，這同樣是從性能角度考慮的。但是，如果服務器在任何給定的時間，都會爲大量I/O請求提供服務，便應考慮使用I/O完成端口模型，從而獲得更佳的性能。