Windows五种IO模型性能分析和Linux五种IO模型性能分析
Windows五種IO模型性能分析和Linux五種IO模型性能分析
http://blog.csdn.net/jay900323/article/details/18141217
http://blog.csdn.net/jay900323/article/details/18140847
重疊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完成端口模型，從而獲得更佳的性能。
?
?
socket阻塞與非阻塞，同步與異步
?
作者：huangguisu
?
?
?
?
1. 概念理解
?
?
?
? ? ?在進行網絡編程時，我們常常見到同步(Sync)/異步(Async)，阻塞(Block)/非阻塞(Unblock)四種調用方式：
同步：
??????所謂同步，就是在發出一個功能調用時，在沒有得到結果之前，該調用就不返回。也就是必須一件一件事做,等前一件做完了才能做下一件事。
?
?
?
例如普通B/S模式（同步）：提交請求->等待服務器處理->處理完畢返回?這個期間客戶端瀏覽器不能干任何事
?
異步：
??????異步的概念和同步相對。當一個異步過程調用發出后，調用者不能立刻得到結果。實際處理這個調用的部件在完成后，通過狀態、通知和回調來通知調用者。
?
? ? ?例如 ajax請求（異步）:?請求通過事件觸發->服務器處理（這是瀏覽器仍然可以作其他事情）->處理完畢
?
阻塞
?????阻塞調用是指調用結果返回之前，當前線程會被掛起（線程進入非可執行狀態，在這個狀態下，cpu不會給線程分配時間片，即線程暫停運行）。函數只有在得到結果之后才會返回。
?
? ? ?有人也許會把阻塞調用和同步調用等同起來，實際上他是不同的。對于同步調用來說，很多時候當前線程還是激活的，只是從邏輯上當前函數沒有返回而已。?例如，我們在socket中調用recv函數，如果緩沖區中沒有數據，這個函數就會一直等待，直到有數據才返回。而此時，當前線程還會繼續處理各種各樣的消息。
?
非阻塞
??????非阻塞和阻塞的概念相對應，指在不能立刻得到結果之前，該函數不會阻塞當前線程，而會立刻返回。
對象的阻塞模式和阻塞函數調用
對象是否處于阻塞模式和函數是不是阻塞調用有很強的相關性，但是并不是一一對應的。阻塞對象上可以有非阻塞的調用方式，我們可以通過一定的API去輪詢狀?態，在適當的時候調用阻塞函數，就可以避免阻塞。而對于非阻塞對象，調用特殊的函數也可以進入阻塞調用。函數select就是這樣的一個例子。
?
?
?
1. 同步，就是我調用一個功能，該功能沒有結束前，我死等結果。
2. 異步，就是我調用一個功能，不需要知道該功能結果，該功能有結果后通知我（回調通知）
3. 阻塞， ? ? ?就是調用我（函數），我（函數）沒有接收完數據或者沒有得到結果之前，我不會返回。
4. 非阻塞， ?就是調用我（函數），我（函數）立即返回，通過select通知調用者
?
?
?
同步IO和異步IO的區別就在于：數據拷貝的時候進程是否阻塞！
?
阻塞IO和非阻塞IO的區別就在于：應用程序的調用是否立即返回！
對于舉個簡單c/s 模式：
?
?
?
同步：提交請求->等待服務器處理->處理完畢返回這個期間客戶端瀏覽器不能干任何事 異步：請求通過事件觸發->服務器處理（這是瀏覽器仍然可以作其他事情）->處理完畢?
同步和異步都只針對于本機SOCKET而言的。?
同步和異步,阻塞和非阻塞,有些混用,其實它們完全不是一回事,而且它們修飾的對象也不相同。 阻塞和非阻塞是指當進程訪問的數據如果尚未就緒,進程是否需要等待,簡單說這相當于函數內部的實現區別,也就是未就緒時是直接返回還是等待就緒;
而同步和異步是指訪問數據的機制,同步一般指主動請求并等待I/O操作完畢的方式,當數據就緒后在讀寫的時候必須阻塞(區別就緒與讀寫二個階段,同步的讀寫必須阻塞),異步則指主動請求數據后便可以繼續處理其它任務,隨后等待I/O,操作完畢的通知,這可以使進程在數據讀寫時也不阻塞。(等待"通知")
?
?
1. Linux下的五種I/O模型
?
1)阻塞I/O（blocking I/O） 2)非阻塞I/O?（nonblocking I/O） 3) I/O復用(select 和poll)?（I/O multiplexing） 4)信號驅動I/O?（signal driven I/O (SIGIO)） 5)異步I/O?（asynchronous I/O (the POSIX aio_functions)）
?
前四種都是同步，只有最后一種才是異步IO。
阻塞I/O模型：
????????簡介：進程會一直阻塞，直到數據拷貝完成
???? 應用程序調用一個IO函數，導致應用程序阻塞，等待數據準備好。 如果數據沒有準備好，一直等待….數據準備好了，從內核拷貝到用戶空間,IO函數返回成功指示。
阻塞I/O模型圖：在調用recv()/recvfrom（）函數時，發生在內核中等待數據和復制數據的過程。
? ? 當調用recv()函數時，系統首先查是否有準備好的數據。如果數據沒有準備好，那么系統就處于等待狀態。當數據準備好后，將數據從系統緩沖區復制到用戶空間，然后該函數返回。在套接應用程序中，當調用recv()函數時，未必用戶空間就已經存在數據，那么此時recv()函數就會處于等待狀態。
?
? ? ?當使用socket()函數和WSASocket()函數創建套接字時，默認的套接字都是阻塞的。這意味著當調用Windows Sockets API不能立即完成時，線程處于等待狀態，直到操作完成。
? ? 并不是所有Windows Sockets API以阻塞套接字為參數調用都會發生阻塞。例如，以阻塞模式的套接字為參數調用bind()、listen()函數時，函數會立即返回。將可能阻塞套接字的Windows Sockets API調用分為以下四種:
? ? 1．輸入操作：?recv()、recvfrom()、WSARecv()和WSARecvfrom()函數。以阻塞套接字為參數調用該函數接收數據。如果此時套接字緩沖區內沒有數據可讀，則調用線程在數據到來前一直睡眠。
? ? 2．輸出操作：?send()、sendto()、WSASend()和WSASendto()函數。以阻塞套接字為參數調用該函數發送數據。如果套接字緩沖區沒有可用空間，線程會一直睡眠，直到有空間。
? ? 3．接受連接：accept()和WSAAcept()函數。以阻塞套接字為參數調用該函數，等待接受對方的連接請求。如果此時沒有連接請求，線程就會進入睡眠狀態。
? ?4．外出連接：connect()和WSAConnect()函數。對于TCP連接，客戶端以阻塞套接字為參數，調用該函數向服務器發起連接。該函數在收到服務器的應答前，不會返回。這意味著TCP連接總會等待至少到服務器的一次往返時間。
使用阻塞模式的套接字，開發網絡程序比較簡單，容易實現。當希望能夠立即發送和接收數據，且處理的套接字數量比較少的情況下，使用阻塞模式來開發網絡程序比較合適。
? ? 阻塞模式套接字的不足表現為，在大量建立好的套接字線程之間進行通信時比較困難。當使用“生產者-消費者”模型開發網絡程序時，為每個套接字都分別分配一個讀線程、一個處理數據線程和一個用于同步的事件，那么這樣無疑加大系統的開銷。其最大的缺點是當希望同時處理大量套接字時，將無從下手，其擴展性很差
非阻塞IO模型?
?
?
?
簡介：非阻塞IO通過進程反復調用IO函數（多次系統調用，并馬上返回）；在數據拷貝的過程中，進程是阻塞的；?
?
?
???????
?
?????? 我們把一個SOCKET接口設置為非阻塞就是告訴內核，當所請求的I/O操作無法完成時，不要將進程睡眠，而是返回一個錯誤。這樣我們的I/O操作函數將不斷的測試數據是否已經準備好，如果沒有準備好，繼續測試，直到數據準備好為止。在這個不斷測試的過程中，會大量的占用CPU的時間。
?
? ? 把SOCKET設置為非阻塞模式，即通知系統內核：在調用Windows Sockets API時，不要讓線程睡眠，而應該讓函數立即返回。在返回時，該函數返回一個錯誤代碼。圖所示，一個非阻塞模式套接字多次調用recv()函數的過程。前三次調用recv()函數時，內核數據還沒有準備好。因此，該函數立即返回WSAEWOULDBLOCK錯誤代碼。第四次調用recv()函數時，數據已經準備好，被復制到應用程序的緩沖區中，recv()函數返回成功指示，應用程序開始處理數據。
?
?
? ? ?當使用socket()函數和WSASocket()函數創建套接字時，默認都是阻塞的。在創建套接字之后，通過調用ioctlsocket()函數，將該套接字設置為非阻塞模式。Linux下的函數是:fcntl().
??? 套接字設置為非阻塞模式后，在調用Windows Sockets API函數時，調用函數會立即返回。大多數情況下，這些函數調用都會調用“失敗”，并返回WSAEWOULDBLOCK錯誤代碼。說明請求的操作在調用期間內沒有時間完成。通常，應用程序需要重復調用該函數，直到獲得成功返回代碼。
?
??? 需要說明的是并非所有的Windows Sockets API在非阻塞模式下調用，都會返回WSAEWOULDBLOCK錯誤。例如，以非阻塞模式的套接字為參數調用bind()函數時，就不會返回該錯誤代碼。當然，在調用WSAStartup()函數時更不會返回該錯誤代碼，因為該函數是應用程序第一調用的函數，當然不會返回這樣的錯誤代碼。
?
??? 要將套接字設置為非阻塞模式，除了使用ioctlsocket()函數之外，還可以使用WSAAsyncselect()和WSAEventselect()函數。當調用該函數時，套接字會自動地設置為非阻塞方式。
?
由于使用非阻塞套接字在調用函數時，會經常返回WSAEWOULDBLOCK錯誤。所以在任何時候，都應仔細檢查返回代碼并作好對“失敗”的準備。應用程序連續不斷地調用這個函數，直到它返回成功指示為止。上面的程序清單中，在While循環體內不斷地調用recv()函數，以讀入1024個字節的數據。這種做法很浪費系統資源。
?
??? 要完成這樣的操作，有人使用MSG_PEEK標志調用recv()函數查看緩沖區中是否有數據可讀。同樣，這種方法也不好。因為該做法對系統造成的開銷是很大的，并且應用程序至少要調用recv()函數兩次，才能實際地讀入數據。較好的做法是，使用套接字的“I/O模型”來判斷非阻塞套接字是否可讀可寫。
?
??? 非阻塞模式套接字與阻塞模式套接字相比，不容易使用。使用非阻塞模式套接字，需要編寫更多的代碼，以便在每個Windows Sockets API函數調用中，對收到的WSAEWOULDBLOCK錯誤進行處理。因此，非阻塞套接字便顯得有些難于使用。
?
??? 但是，非阻塞套接字在控制建立的多個連接，在數據的收發量不均，時間不定時，明顯具有優勢。這種套接字在使用上存在一定難度，但只要排除了這些困難，它在功能上還是非常強大的。通常情況下，可考慮使用套接字的“I/O模型”，它有助于應用程序通過異步方式，同時對一個或多個套接字的通信加以管理。
?
IO復用模型：
?
?????????????簡介：主要是select和epoll；對一個IO端口，兩次調用，兩次返回，比阻塞IO并沒有什么優越性；關鍵是能實現同時對多個IO端口進行監聽；
?
? ?? ?I/O復用模型會用到select、poll、epoll函數，這幾個函數也會使進程阻塞，但是和阻塞I/O所不同的的，這兩個函數可以同時阻塞多個I/O操作。而且可以同時對多個讀操作，多個寫操作的I/O函數進行檢測，直到有數據可讀或可寫時，才真正調用I/O操作函數。
?
?
信號驅動IO
?
?
?
? ??簡介：兩次調用，兩次返回；
?
????首先我們允許套接口進行信號驅動I/O,并安裝一個信號處理函數，進程繼續運行并不阻塞。當數據準備好時，進程會收到一個SIGIO信號，可以在信號處理函數中調用I/O操作函數處理數據。
?
?
異步IO模型
?
???????? 簡介：數據拷貝的時候進程無需阻塞。
?
? ? ?當一個異步過程調用發出后，調用者不能立刻得到結果。實際處理這個調用的部件在完成后，通過狀態、通知和回調來通知調用者的輸入輸出操作
同步IO引起進程阻塞，直至IO操作完成。 異步IO不會引起進程阻塞。 IO復用是先通過select調用阻塞。
?
?
?
5個I/O模型的比較：
?
?
?
?
?
?
?
1. select、poll、epoll簡介
?
epoll跟select都能提供多路I/O復用的解決方案。在現在的Linux內核里有都能夠支持，其中epoll是Linux所特有，而select則應該是POSIX所規定，一般操作系統均有實現
?
?
?
select：
?
select本質上是通過設置或者檢查存放fd標志位的數據結構來進行下一步處理。這樣所帶來的缺點是：
?
1、 單個進程可監視的fd數量被限制，即能監聽端口的大小有限。
?
????? 一般來說這個數目和系統內存關系很大，具體數目可以cat /proc/sys/fs/file-max察看。32位機默認是1024個。64位機默認是2048.
?
2、 對socket進行掃描時是線性掃描，即采用輪詢的方法，效率較低：
?
?????? 當套接字比較多的時候，每次select()都要通過遍歷FD_SETSIZE個Socket來完成調度,不管哪個Socket是活躍的,都遍歷一遍。這會浪費很多CPU時間。如果能給套接字注冊某個回調函數，當他們活躍時，自動完成相關操作，那就避免了輪詢，這正是epoll與kqueue做的。
?
3、需要維護一個用來存放大量fd的數據結構，這樣會使得用戶空間和內核空間在傳遞該結構時復制開銷大
?
poll：
?
poll本質上和select沒有區別，它將用戶傳入的數組拷貝到內核空間，然后查詢每個fd對應的設備狀態，如果設備就緒則在設備等待隊列中加入一項并繼續遍歷，如果遍歷完所有fd后沒有發現就緒設備，則掛起當前進程，直到設備就緒或者主動超時，被喚醒后它又要再次遍歷fd。這個過程經歷了多次無謂的遍歷。
?
它沒有最大連接數的限制，原因是它是基于鏈表來存儲的，但是同樣有一個缺點：
?
1、大量的fd的數組被整體復制于用戶態和內核地址空間之間，而不管這樣的復制是不是有意義。????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? 2、poll還有一個特點是“水平觸發”，如果報告了fd后，沒有被處理，那么下次poll時會再次報告該fd。
epoll:
epoll支持水平觸發和邊緣觸發，最大的特點在于邊緣觸發，它只告訴進程哪些fd剛剛變為就需態，并且只會通知一次。還有一個特點是，epoll使用“事件”的就緒通知方式，通過epoll_ctl注冊fd，一旦該fd就緒，內核就會采用類似callback的回調機制來激活該fd，epoll_wait便可以收到通知
?
epoll的優點：
?
?
?
1、沒有最大并發連接的限制，能打開的FD的上限遠大于1024（1G的內存上能監聽約10萬個端口）； 2、效率提升，不是輪詢的方式，不會隨著FD數目的增加效率下降。只有活躍可用的FD才會調用callback函數； ??????即Epoll最大的優點就在于它只管你“活躍”的連接，而跟連接總數無關，因此在實際的網絡環境中，Epoll的效率就會遠遠高于select和poll。?
3、?內存拷貝，利用mmap()文件映射內存加速與內核空間的消息傳遞；即epoll使用mmap減少復制開銷。select、poll、epoll 區別總結：
?
?
?
1、支持一個進程所能打開的最大連接數
?
| select | 單個進程所能打開的最大連接數有FD_SETSIZE宏定義，其大小是32個整數的大小（在32位的機器上，大小就是32*32，同理64位機器上FD_SETSIZE為32*64），當然我們可以對進行修改，然后重新編譯內核，但是性能可能會受到影響，這需要進一步的測試。 |
| poll | poll本質上和select沒有區別，但是它沒有最大連接數的限制，原因是它是基于鏈表來存儲的 |
| epoll | 雖然連接數有上限，但是很大，1G內存的機器上可以打開10萬左右的連接，2G內存的機器可以打開20萬左右的連接 |
?
2、FD劇增后帶來的IO效率問題
?
| select | 因為每次調用時都會對連接進行線性遍歷，所以隨著FD的增加會造成遍歷速度慢的“線性下降性能問題”。 |
| poll | 同上 |
| epoll | 因為epoll內核中實現是根據每個fd上的callback函數來實現的，只有活躍的socket才會主動調用callback，所以在活躍socket較少的情況下，使用epoll沒有前面兩者的線性下降的性能問題，但是所有socket都很活躍的情況下，可能會有性能問題。 |
?
3、 消息傳遞方式
?
| select | 內核需要將消息傳遞到用戶空間，都需要內核拷貝動作 |
| poll | 同上 |
| epoll | epoll通過內核和用戶空間共享一塊內存來實現的。 |
?
總結：
?
綜上，在選擇select，poll，epoll時要根據具體的使用場合以及這三種方式的自身特點。
?
1、表面上看epoll的性能最好，但是在連接數少并且連接都十分活躍的情況下，select和poll的性能可能比epoll好，畢竟epoll的通知機制需要很多函數回調。
?
2、select低效是因為每次它都需要輪詢。但低效也是相對的，視情況而定，也可通過良好的設計改善
?
https://www.cnblogs.com/lixinjie/p/a-post-tell-clearly-about-io-multiplexing-and-async-io.html
真正的多路復用技術
多路復用技術原本指的是，在通信方面，多種信號或數據（從宏觀上看）交織在一起，使用同一條傳輸通道進行傳輸。
這樣做的目的，一方面可以充分利用通道的傳輸能力，另一方面自然是省時省力省錢啦。
其實這個概念非常的“生活化”，隨手就可以舉個例子：
一條小水渠里水在流，在一端往里倒入大量乒乓球，在另一端用網進行過濾，把乒乓球和水流分開。
這就是一個比較“土”的多路復用，首先在發射端把多種信號或數據進行“混合”，接著是在通道上進行傳輸，最后在接收端“分離”出自己需要的信號或數據。
相信大家都看出來了，這里的重點其實就是處理好“混合”和“分離”，對于不同的信號或數據，有不同的處理方法。
比如以前的有線電視是模擬信號，即電磁波。一家一般只有一根信號線，但可以同時接多個電視，每個電視任意換臺，互不影響。
這是由于不同頻率的波可以混合和分離。（當然，可能不是十分準確，明白意思就行了。）
再比如城市的高鐵站一般都有數個站臺供高鐵（同時）停靠，但城市間的高鐵軌道單方向只有一條，如何保證那么多趟高鐵安全運行呢？
很明顯是分時使用，每趟高鐵都有自己的時刻。多趟高鐵按不同的時刻出站相當于混合，按不同的時刻進站相當于分離。
總結一下，多路指的是多種不同的信號或數據或其它事物，復用指的是共用同一個物理鏈路或通道或載體。
可見，多路復用技術是一種一對多的模型，“多”的這一方復用了“一”的這一方。
其實，一對多的模型主要體現在“公用”上或“共享”上。
這種處理模式就是被稱為的多路復用I/O，多路指的是多個Socket通道，復用指的是只用一個線程來管理它們。
就飯店而言，究竟幾張桌子配一個跑腿服務員，幾張桌子配一個點餐服務員，經過一段時間運行，一定會有一個最優解。
就程序而言，究竟需要幾個選擇器線程，幾個工作線程，經過評估測試后，也會有一個最優解。
一旦達到最優解后，就不可能再提升了，這同樣是由多路復用這種一對多的形式所限制的。就像一對一的形式限制一樣。
人們的追求是無止境的，如何對多路復用繼續提升呢？答案一定是具有顛覆性的，即拋棄多路復用，采用全新的形式。
還以飯店為例，如何在最優解的情況下，既要繼續減少服務員數量，還要使效率提升呢？可能有些朋友已經猜到了，那就是拋棄服務員服務客人這種模式，把飯店改成自助餐廳。
對比與結論：
處理同樣的20個請求，一個需要用20個線程，一個需要用6個線程，一個需要3個線程，又節省了50%線程數。
BIO是阻塞IO，可以是同步阻塞，也可以是異步阻塞。AIO是異步IO，只有異步非阻塞這一種。因此沒有同步非阻塞這種說法，因為同步一定是阻塞的。
分配一個讀線程、一個處理數據線程和一個用于同步的事件
一個數據庫socket線程 -》同時對多個硬盤發過來的IO端口數據
簡介：主要是select和epoll；對一個IO端口，兩次調用，兩次返回，比阻塞IO并沒有什么優越性；關鍵是能實現同時對多個IO端口進行監聽；
異步IO多路復用
?
轉載于:https://www.cnblogs.com/MYSQLZOUQI/p/4231463.html
總結
以上是生活随笔為你收集整理的Windows五种IO模型性能分析和Linux五种IO模型性能分析的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： C# winform 窗体怎么隐藏标题栏
- 下一篇： Linux实现的IEEE 802.q V