• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            麒麟子

            ~~

            導(dǎo)航

            <2013年3月>
            242526272812
            3456789
            10111213141516
            17181920212223
            24252627282930
            31123456

            統(tǒng)計

            常用鏈接

            留言簿(12)

            隨筆分類

            隨筆檔案

            Friends

            WebSites

            積分與排名

            最新隨筆

            最新評論

            閱讀排行榜

            評論排行榜

            請教大家一個關(guān)于EPOLLET和EPOLLLT的問題

            今天在查看EPOLLET和EPOLLLT的細節(jié)的時候,發(fā)現(xiàn)一篇文章。 但不知文中說的是否有道理,望各位大大給個明確的答復(fù)。
            游戲服務(wù)器,我們用的是ET方式。

            剖析 epoll ET/LT 觸發(fā)方式的性能差異誤解(定性分析)


            平時大家使用 epoll 時都知道其事件觸發(fā)模式有默認的 level-trigger 模式和通過 EPOLLET 啟用的 edge-trigger 模式兩種。從 epoll 發(fā)展歷史來看,它剛誕生時只有 edge-trigger 模式,后來因容易產(chǎn)生 race-cond 且不易被開發(fā)者理解,又增加了 level-trigger 模式并作為默認處理方式。

            二者的差異在于 level-trigger 模式下只要某個 fd 處于 readable/writable 狀態(tài),無論什么時候進行 epoll_wait 都會返回該 fd;而 edge-trigger 模式下只有某個 fd 從 unreadable 變?yōu)?readable 或從 unwritable 變?yōu)?writable 時,epoll_wait 才會返回該 fd。

            通常的誤區(qū)是:level-trigger 模式在 epoll 池中存在大量 fd 時效率要顯著低于 edge-trigger 模式。

            但從 kernel 代碼來看,edge-trigger/level-trigger 模式的處理邏輯幾乎完全相同,差別僅在于 level-trigger 模式在 event 發(fā)生時不會將其從 ready list 中移除,略為增大了 event 處理過程中 kernel space 中記錄數(shù)據(jù)的大小。

            然而,edge-trigger 模式一定要配合 user app 中的 ready list 結(jié)構(gòu),以便收集已出現(xiàn) event 的 fd,再通過 round-robin 方式挨個處理,以此避免通信數(shù)據(jù)量很大時出現(xiàn)忙于處理熱點 fd 而導(dǎo)致非熱點 fd 餓死的現(xiàn)象。統(tǒng)觀 kernel 和 user space,由于 user app 中 ready list 的實現(xiàn)千奇百怪,不一定都經(jīng)過仔細的推敲優(yōu)化,因此 edge-trigger 的總內(nèi)存開銷往往還大于 level-trigger 的開銷。

            一般號稱 edge-trigger 模式的優(yōu)勢在于能夠減少 epoll 相關(guān)系統(tǒng)調(diào)用,這話不假,但 user app 里可不是只有 epoll 相關(guān)系統(tǒng)調(diào)用吧?為了繞過餓死問題,edge-trigger 模式的 user app 要自行進行 read/write 循環(huán)處理,這其中增加的系統(tǒng)調(diào)用和減少的 epoll 系統(tǒng)調(diào)用加起來,有誰能說一定就能明顯地快起來呢?

            實際上,epoll_wait 的效率是 O(ready fd num) 級別的,因此 edge-trigger 模式的真正優(yōu)勢在于減少了每次 epoll_wait 可能需要返回的 fd 數(shù)量,在并發(fā) event 數(shù)量極多的情況下能加快 epoll_wait 的處理速度,但別忘了這只是針對 epoll 體系自己而言的提升,與此同時 user app 需要增加復(fù)雜的邏輯、花費更多的 cpu/mem 與其配合工作,總體性能收益究竟如何?只有實際測量才知道,無法一概而論。不過,為了降低處理邏輯復(fù)雜度,常用的事件處理庫大部分都選擇了 level-trigger 模式(如 libevent、boost::asio等)

            結(jié)論:
            • epoll 的 edge-trigger 和 level-trigger 模式處理邏輯差異極小,性能測試結(jié)果表明常規(guī)應(yīng)用場景 中二者性能差異可以忽略。
            • 使用 edge-trigger 的 user app 比使用 level-trigger 的邏輯復(fù)雜,出錯概率更高。
            • edge-trigger 和 level-trigger 的性能差異主要在于 epoll_wait 系統(tǒng)調(diào)用的處理速度,是否是 user app 的性能瓶頸需要視應(yīng)用場景而定,不可一概而論。

            歡迎就此話題進行深入調(diào)研、討論!

            參考資料:
            • linux kernel source:fs/eventpoll.c
            • “Comparing and Evaluating epoll, select, and poll Event
            Mechanisms”:http://bcr2.uwaterloo.ca/~brecht/papers/getpaper.php?file=ols-2004.pdf
            • “Edge-triggered interfaces are too difficult?”:http://lwn.net/Articles/25137/

            By QingWu


            posted on 2013-02-25 13:05 麒麟子 閱讀(7794) 評論(1)  編輯 收藏 引用 所屬分類: Programming

            評論

            # re: 請教大家一個關(guān)于EPOLLET和EPOLLLT的問題 2013-02-26 16:14 peakflys

            其實這個問題我之前在一篇blog里已經(jīng)討論過(http://www.shnenglu.com/peakflys/archive/2012/08/26/188344.aspx)
            我現(xiàn)在的結(jié)論是:ET模式在網(wǎng)絡(luò)層方面的效率確實比LT要高。
            主要表現(xiàn)在:
            1、網(wǎng)絡(luò)IO比較小時,send buffer表現(xiàn)為一直可寫,如果網(wǎng)絡(luò)主循環(huán)沒有延時操作的話,epoll_wait每次調(diào)用都會馬上有事件返回,導(dǎo)致不必要的CPU空耗。
            2、在網(wǎng)絡(luò)IO比較大,尤其是連接數(shù)比較多的時候,每次epoll_wait調(diào)用時LT模式肯定比ET模式多,因為之后需要對ready list 進行遍歷處理,如果處理邏輯比較復(fù)雜,或者之前反饋的事件數(shù)LT比ET多很多的話,這時候效率差異就比較明顯了。

            還是那句話,ET模式在網(wǎng)絡(luò)主循環(huán)處理的效率肯定比LT模式要高,至于高多少,視具體應(yīng)用和具體實現(xiàn)。當然ET模式的代價就是增加了網(wǎng)絡(luò)層的邏輯處理復(fù)雜度,必須保證時刻知道fd當前的狀態(tài)。  回復(fù)  更多評論   

            国产亚洲美女精品久久久久狼| 久久香蕉国产线看观看精品yw| 日本精品久久久久中文字幕8| 国产ww久久久久久久久久| 久久久久久毛片免费看| 亚洲va国产va天堂va久久| 久久夜色精品国产亚洲| 久久人妻AV中文字幕| 久久99国产乱子伦精品免费| 亚洲国产精品狼友中文久久久| 亚洲伊人久久大香线蕉综合图片| 99久久免费国产精品| 亚洲色大成网站WWW久久九九| 国产巨作麻豆欧美亚洲综合久久| 漂亮人妻被中出中文字幕久久| 亚洲国产天堂久久综合网站| 久久久精品久久久久影院| 激情五月综合综合久久69| 亚洲精品乱码久久久久久久久久久久 | 午夜精品久久久久久久久| 国产精品成人久久久久三级午夜电影| 亚洲午夜无码久久久久| 久久亚洲AV无码精品色午夜| 久久人搡人人玩人妻精品首页 | 久久人人爽人人爽人人片AV高清 | 久久久综合九色合综国产| 色综合久久久久久久久五月| 亚洲国产精品一区二区三区久久| 久久久久18| 欧美国产精品久久高清| 久久这里有精品视频| 国产69精品久久久久9999| 亚洲精品高清久久| 狠狠色丁香婷婷久久综合不卡| 丁香五月网久久综合| 欧美日韩中文字幕久久伊人| 国产精品99久久99久久久| 99久久久精品免费观看国产| 2021久久国自产拍精品| 久久综合久久久| 国产精品伦理久久久久久|