回覆列表
-
1 # 零一研究院
-
2 # lehoon
應該是存在大量不活躍的連線時候,epoll會比select高效,因為select會進行全量遍歷。在連線數不多或者全部活躍的場景下,select可能比epoll高效。
-
3 # jwzhang0809
select和poll都是輪詢指定的檔案描述符陣列,返回哪些可讀、可寫、異常。epoll是查詢epoll控制代碼,獲取可讀、可寫、異常的檔案描述符。
select對陣列元素的檢查,需要沒個描述符去判斷。epoll只需要返回當前有狀態(或狀態切換)的註冊到了該epoll控制代碼的描述符。
很多答案會說明使用者態和系統態切換是核心效能的關鍵,個人習慣認為是軟體層次和介面設計的必然結果:複用陣列的構建是使用者程式碼,epoll控制代碼內部實現是系統執行。
嚴格的說,這個說法是不準確的,epoll的效能並不總是優於select.
首先需要了解下select和epoll的基本原理。
假設我們現在有100個socket連線,select的做法是,每隔一段時間輪詢這100個連線,判斷是否有網路事件,如果有,則進行處理。
epoll的做法是,建立一個連結串列,然後告訴作業系統,那100個連線如果哪個發生了網路事件,就給我放到這個連結串列裡,然後epoll每隔一段時間就檢查下這個連結串列是否有元素,有的話就進行處理。
對比不難發現,epoll相對於select,大大降低了空輪詢的次數,提高了輪詢的效率,同時,由於select輪詢時,需要將所有連線的fd從核心複製到使用者空間,增加了io開銷,epoll在這方面用mmap進行了最佳化。
不過,不能簡單的說誰更好。
比如,這100個連線,如果網路活動十分頻繁,那麼select每次輪詢時,只有很少或者根本沒有空輪詢,那select的無用功就很少,相反,epoll由於多了一步操作,效能反而更差。
因此,select適用於業務時間較短的短連結,比如一般的http服務。epoll適用於連線時間較長但是網路活動不頻繁的場景,比如聊天室。