# re: 論epoll的使用[未登錄] 2012-08-27 10:33 春秋十二月

LT模式下，只要空間可寫，則寫事件不斷被觸發(fā)，CPU占用較高，如果不轉(zhuǎn)為ET模式，怎么解決這一問題？  回復  更多評論   

# re: 論epoll的使用[未登錄] 2012-08-27 16:36 春秋十二月

@peakflys
fd寫事件被觸發(fā)，是因為sock底層緩沖區(qū)有大于某個閾值的空閑空間，和應用層有無數(shù)據(jù)待寫沒有關(guān)系吧  回復  更多評論   

# re: 論epoll的使用 2012-08-28 10:51 peakflys

@春秋十二月
謝謝春秋仁兄的指教，我是這么認為的。send buffer不滿時觸發(fā)的寫事件，應該不至于引起CPU的占用過高(OS里本身也有很多納秒級的死循環(huán))，如果過高說明輪詢時的處理函數(shù)太耗CPU了，應該是可以優(yōu)化的，另外輪詢時間也可以設(shè)置的長一些，當然有些應用需要這么準確、及時。如果這樣的話，我認為可以這樣改進：在一次網(wǎng)絡(luò)主循環(huán)里調(diào)用兩次epoll_wait，第一次是及時的(例如1ms)用于處理讀和錯誤事件，第二次是稍微長的(例如30~50ms，視情況定)用于處理讀、寫等事件。為了達到這種效果，我們可以 封裝兩種send方式，一種是使用epoll觸發(fā)的寫，另外一種是緊急的立即寫(當然寫時可以調(diào)用poll等檢測一下是否可寫)。這樣效率應該跟得上了，復雜度和出錯成都也沒有ET模式高。  回復  更多評論   

# re: 論epoll的使用 2012-08-29 17:07 唐詩

樓主沒有說到重點，需要注意的是寫事件。
a. 對于et來說，應用層向tcp緩沖區(qū)寫，有可能應用層數(shù)據(jù)寫完了，但是tcp緩沖沒有寫到EAGAIN事件，那么此時需要在應用層做個標記，表明tcp緩沖區(qū)是可寫的，否則，由于et是只觸發(fā)一次，應用層就再也不會被通知緩沖區(qū)可寫了。
b. 對于lt來說，應用層確實會每次通知可寫事件，問題在于，如果應用層沒數(shù)據(jù)需要往Tcp緩沖區(qū)寫的話，epoll還是會不停的通知你可寫，這時候需要把描述符移出epoll，避免多次無效的通知
http://www.cnblogs.com/egametang/archive/2012/07/30/2615808.html  回復  更多評論   

# re: 論epoll的使用 2012-08-29 17:08 唐詩

事實上et要比lt簡單的多  回復  更多評論   

# re: 論epoll的使用 2012-08-30 07:34 peakflys

謝謝唐詩的回復和指教，你指出的
a問題：在文中寫ET模式時已經(jīng)說了一部分，不過沒有說寫事件處理完之后，send buffer仍然可寫時怎么處理，因為這個本身就是我認為的ET模式弊端之一，因為挺麻煩也挺易出錯。
b問題：當時寫這篇短文時確實沒有特別考慮，不過在評論里面 春秋十二月仁兄指出了這個問題，唐詩兄給出的方法是每次把數(shù)據(jù)寫完之后把它移出epoll監(jiān)聽隊列，以后有新的寫數(shù)據(jù)時再加入寫事件到隊列，不過個人感覺這種方法不是很理想，除了自己寫著難受之外，因為從2.6.10內(nèi)核之后 epoll內(nèi)部隊列的數(shù)據(jù)結(jié)構(gòu)變成了RB_TREE，游戲中寫數(shù)據(jù)很頻繁(尤其是大規(guī)模玩家在線時)，這樣頻繁的調(diào)整RB_TREE，性能損耗應該會不小。我在給春秋十二月仁兄的回復中給出了我的大致解決方法(參看上面評論)，有什么不完整或者不對的地方，還請?zhí)圃娦种附袒蛘哙]件交流 peakflys@gmail.com
至于唐詩兄說的et要比lt簡單，這個可能是用et用的多了，很多細節(jié)錯誤已經(jīng)有了自己固定成熟的解決方案了才說出這樣的結(jié)論。ET如果保證每次觸發(fā)的事件都可以及時有效的處理完全(當然 個人認為不容易，有時候還要自己處理一些本該TCP處理的東西)ET模式還是可以作為首選的，否則會表現(xiàn)出通訊過程中應用上層各種詭異的問題…… @唐詩  回復  更多評論   

# re: 論epoll的使用 2012-08-30 11:09 唐詩

正因為覺得移出epoll隊列不好，但是不移除也不好，所以et是比較好的方式
代碼其實相當簡單。

write_list_是應用層緩沖區(qū)，在epoll寫事件來的時候，應用層緩沖區(qū)為空的話
設(shè)置socket 可寫。下次往應用層緩沖區(qū)寫數(shù)據(jù)時，檢查socket是否可寫，如果可寫則調(diào)用HandleWrite即可。緩沖區(qū)寫滿的時候設(shè)置socket不可寫就行了。

HandleWrite有兩個調(diào)用途徑，一個是寫事件觸發(fā)，一個是應用層觸發(fā)(socket有is_writable標記）。

void HandleWrite()
while (true) {
// 應用層緩沖區(qū)全部寫到TCP緩沖區(qū)了, 此時TCP緩沖區(qū)還是可寫
// et模式下不會再通知應用層, 所以設(shè)置下socket writable狀態(tài)
// 下次應用層數(shù)據(jù)來的時候檢查該狀態(tài)
if (write_list_.TotalSize() == 0) {
socket_.set_is_writable(true);
return;
}
int n = write(fd, write_list_.ReadPoint(), write_list_.readable_size());
const int error_no = errno;
if (n == -1) { // 寫異常
if (error_no == EINTR) {
continue;
}
// 緩沖區(qū)已寫滿, 需要等寫事件
if (error_no == EAGAIN) {
socket_.set_is_writable(false);
return;
} else {
HandleError(error_no);
return;
}
} else { // 寫正常
write_list_.ReadAdvance(n);
}
}  回復  更多評論   

# re: 論epoll的使用 2012-08-30 14:11 peakflys

恩，唐詩兄在socket上加入標記位的辦法是可以很好解決ET模式的寫問題(上述代碼中唐詩兄應該加上write之后 0==n 的情況，及時斷掉正常中斷的socket，而不是認為寫正常，馬上調(diào)整發(fā)送緩存)
謝謝唐詩兄的指教，不過如果使用LT模式，唐詩兄會發(fā)現(xiàn)更簡單，呵呵。不知道你們一個網(wǎng)絡(luò)主線程掛載多少socket？ @唐詩
  回復  更多評論   

# re: 論epoll的使用 2012-08-30 14:53 唐詩

@peakflys
單線程，壓力測試流量很大，3K都沒有問題，這時已經(jīng)受到帶寬限制了。流量小點10K都可以。我們設(shè)計只需要1K連接就行了，不夠可以加多個網(wǎng)關(guān)服，所以綽綽有余了  回復  更多評論   

# re: 論epoll的使用 2012-08-30 15:48 peakflys

恩，看來服務器性能還不錯，我們單網(wǎng)關(guān)設(shè)計是5K連接，不過使用的是線程池，單個線程掛512個socket，在加上網(wǎng)絡(luò)主循環(huán)有相應優(yōu)化，所以LT模式影響不大，留給上層邏輯很大的擴展空間 @唐詩
  回復  更多評論   

# re: 論epoll的使用[未登錄] 2012-08-31 01:04 春秋十二月

唐工的方法，和我實踐中基本是一樣的，但沒有加標記，而是直接發(fā)，如果碰到EAGAIN，則入隊；如果發(fā)了一部分，則剩下的部分入隊，留在下次寫事件中發(fā)。
簡言之，ET模式的讀寫，需要不斷讀或?qū)懼钡接龅紼AGAIN或出錯，也就是達到邊緣狀態(tài)（空間空或滿），如果后來空間非空或非滿（原因是網(wǎng)絡(luò)收到數(shù)據(jù)或?qū)懗鰯?shù)據(jù)），則讀或?qū)懯录捅挥|發(fā)一次了。  回復  更多評論   

# re: 論epoll的使用 2012-09-01 15:49 zuhd

一直用的是LT，最大鏈接4K，并且沒有把 “沒有寫需求的socket”移出epoll，目前也沒有發(fā)現(xiàn)效率問題。在思考是輪詢的代價大還是移除的代價大？  回復  更多評論   

# re: 論epoll的使用 2012-09-02 11:36 peakflys

@zuhd
移出的代價必然大于輪詢的代價，但是如果LT模式不做寫事件優(yōu)化的話，是在一定程度上影響效率的(影響的程度和掛載的socket數(shù)量有關(guān))，這種影響首先表現(xiàn)在輪詢的次數(shù)上，其次(也應該說主要)是你的發(fā)送函數(shù)上調(diào)用上，因為不管有沒有消息需要發(fā)送，只要send buffer不滿，寫事件都會觸發(fā)，你所封裝的發(fā)送函數(shù)都會調(diào)用。  回復  更多評論   

# re: 論epoll的使用 2013-02-26 16:28 peakflys

經(jīng)過討論最終結(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)用都會馬上有事件返回，導致不必要的CPU空耗，如果加入延時處理，對于一些實時性要求比較高的操作會受到影響，必須耗費額外的邏輯處理。
2、在網(wǎng)絡(luò)IO比較大，尤其是連接數(shù)比較多的時候，每次epoll_wait調(diào)用時LT模式肯定比ET模式多，因為之后需要對ready list 進行遍歷處理，如果處理邏輯比較復雜，或者之前反饋的事件數(shù)LT比ET多很多的話，這時候效率差異就比較明顯了。

ET模式在網(wǎng)絡(luò)主循環(huán)處理的效率肯定比LT模式要高，至于高多少，視具體應用和具體實現(xiàn)而定。當然ET模式的代價就是增加了網(wǎng)絡(luò)層的邏輯處理復雜度，必須手動維護fd當前的狀態(tài)，在數(shù)據(jù)發(fā)送時也不能像LT模式那樣直接丟到fd應用層的buffer中。當然武器是好武器，關(guān)鍵還是看用的人，如果非要把寶劍當菜刀使，那也只能沉默了……  回復  更多評論   

# re: 論epoll的使用 2013-03-01 22:09 Render Donkey

http://www.shnenglu.com/Leaf/archive/2013/02/25/198061.html
我在博客中，也發(fā)表了類似的討論。 博主給了此文鏈接，我順道看過來。
那我也說說我現(xiàn)在的看法。

首先，ET模式比LT模式在處理網(wǎng)絡(luò)IO的時候，ET效率高，這個大家已經(jīng)沒有太多爭論了。

而ET模式換來的代價，就是需要循環(huán)讀取。 而寫事件的監(jiān)測，在我們項目中也是采用的標記法。

我們是按幀發(fā)送網(wǎng)絡(luò)數(shù)據(jù)的。
當發(fā)送數(shù)據(jù)時發(fā)現(xiàn)標志可寫，就將寫緩沖區(qū)中的數(shù)據(jù)寫向SOCKET。
可寫標記僅當寫的時候發(fā)現(xiàn)不可寫時，設(shè)置為false,而由epoll_wait觸發(fā)變?yōu)閠rue. 除此沒有其它改變這個標志的地方。


我想不管是采用LT還是采用ET，都是有原因的。 或者是項目歷史原因，又或者是個人習慣不同。

很多人覺得自己用了LT也沒有發(fā)現(xiàn)問題。 這也是證明了LT是可行的。
不過話又說回來。 SELECT時代，不依然有高并發(fā)的服務器存在么。

所以，LT是可行的，這個肯定毋庸置疑。并且LT后于ET模式出現(xiàn)，也是有其客觀存在的意義的。
但ET模式也有很多人在用，特別是一些追求效率到扣門兒的兄弟中更為多見。


總之，從各位大大的評論中，我理清了這兩個東西的關(guān)系。 也學會用正確的眼光來看待這兩個東西。謝謝大家。  回復  更多評論   

# re: 論epoll的使用 2014-08-06 17:25 呆賊

@peakflys
對于LT下空轉(zhuǎn)的問題，如果socket有寫事件，不要直接放入epoll中，先send，如果出現(xiàn)eagain再放到epoll中處理，這樣做您看如何？  回復  更多評論   

# re: 論epoll的使用[未登錄] 2014-08-06 18:53 peakflys

@呆賊
“如果socket有寫事件，不要直接放入epoll中”？
你的意思應該是epoll不監(jiān)聽寫事件吧？
如果是這個意思的話，你說的可以解決LT模式下CPU空轉(zhuǎn)的問題，不過會引入新的問題，也就是頻繁地修改epoll事件(剛開始EPOLL_OUT不監(jiān)聽，后來send失敗后Add EPOLL_OUT事件，等監(jiān)聽發(fā)送完畢，還要再Del掉EPOLL_OUT事件).
  回復  更多評論