遊戲架構 遊戲架構設計(8)
原文地址:https://blog.csdn.net/erlib/article/details/24301867
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位的機器上,大小就是3232,同理64位機器上FD_SETSIZE為3264),當然我們可以對進行修改,然後重新編譯核心,但是效能可能會受到影響,這需要進一步的測試。
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低效是因為每次它都需要輪詢。但低效也是相對的,視情況而定,
也可通過良好的設計改善
相關文章
- 遊戲引擎架構遊戲引擎架構
- 【程式設計師的遊戲開發之路】 遊戲架構程式設計師遊戲開發架構
- 遊戲架構設計——高效能並行程式設計遊戲架構並行行程程式設計
- 遊戲引擎介紹,架構,設計及實現遊戲引擎架構
- 架構設計思想-微服務架構設計模式架構微服務設計模式
- 架構師修煉之道(二)——架構?設計?架構師?架構
- 架構設計架構
- 架構設計之一——基礎架構架構
- 架構設計之架構的演變架構
- SaaS架構:開放平臺架構設計架構
- 世界觀架構之射擊遊戲技能設定架構遊戲
- Nginx架構設計Nginx架構
- groupcache 架構設計PCA架構
- Tumblr 架構設計架構
- 架構與設計架構
- 遊戲伺服器架構概要遊戲伺服器架構
- 阿里雲架構師解讀三大主流遊戲架構阿里架構遊戲
- 讀《前端架構設計》 兼談架構與框架前端架構框架
- SaaS架構:多租戶系統架構設計架構
- SaaS架構:中央庫存系統架構設計架構
- Go遊戲服務端框架從零搭建(一)— 架構設計Go遊戲服務端框架架構
- 基於滴滴雲的棋牌遊戲服務端架構設計遊戲服務端架構
- 阿里雲架構師解讀四大主流遊戲架構阿里架構遊戲
- 通過遊戲學習計算機架構 - embeddedartistry遊戲計算機架構Dart
- 透過遊戲學習計算機架構 - embeddedartistry遊戲計算機架構Dart
- 阿里P8級架構師淺析秒殺架構設計實踐思路阿里架構
- 遊戲伺服器的常用架構遊戲伺服器架構
- 網站架構設計網站架構
- 架構設計方法論架構
- 面向架構程式設計架構程式設計
- 架構設計(九):估算架構
- 架構設計方法初探架構
- MVP架構設計 初探MVP架構
- 軟體架構設計架構
- WebService Soap架構設計Web架構
- 架構、框架、設計模架構框架
- 學習架構設計架構
- 企業架構設計?架構