高效能網路伺服器選型比較(EPOLL/Libevent/JAVA mina2)

起因
網上很多關於高性伺服器選型的觀點，也有很多爭議，比如C和JAVA的比較，EPOLL和Libevent的比較，爭論不休。包括GLEASY自己提供的中介軟體，也經常受到不少批評和質疑，收到最多的就是關於使用語言的，GLEASY中介軟體多數使用JAVA語言，基於MINA2架構，而且我們內部經過大量的壓力測試和驗證也證明了是效能極高的。關於這一點，在本部落格的其它文章中有大量介紹。
不過是否可以百尺杆頭，更進一步呢？比如選用C語言和基於C語言的開發庫，情況如何呢？
因此，GLEASY架構組做了一系列的實驗，來驗證當前一些主流的高效能網路伺服器開發庫的效能比較起來到底如何。

實驗資料
實驗1：EPOLL(多worker線程，多個線程共用1個epoll,snapshot) C語言
實驗2：Libevent N+1線程(one event-loop per thread) C語言
實驗3：Mina2(JAVA語言）
實驗結果在下面附件中：下載測試檔案:http:/file.111cn.net/upload/2014/3/a.doc

結論
CPU佔用對比圖:

TPS對比圖：

對兩幅圖的解釋：
1. 從TPS（每秒處理的請求資料上來看），三者沒有本質差異，基於JAVA語言的MINA2架構在TPS上絕對不輸於C語言EPOLL和LIBEVENT。而且這三個傢伙的效能表現都很牛很牛，從圖上可以看出，當並發串連在1000左右時，TPS可以達到30萬！
2. EPOLL無論在TPS或者CPU佔用率方面都佔優勢。這是預料之中，畢竟LIBEVENT也好，MINA2也好，在LINUX上面，最終使用也是EPOLL機制，所以只要不犯低級錯誤，原生的EPOLL在效能和CPU消耗方面必然會佔優勢。
3. LIBEVENT和MINA2都在EPOLL基礎上做了大量的封裝工作，比如LIBEVENT的buffer event,Mina2的codec，不可避免造成額外的CPU開銷。其中基於java語言的mina2在CPU上開銷明顯大於C語言的其它方案。甚至有接近2倍的差異。
4. 我們在開發功能複雜的伺服器應用之時，一些基本的工作必須要做，比如buffer,比如codec，這些工作我們自己做，或者交由libevent或者 mina2來做，始終都要去做，是避免不了的，而且我們自己去實現，本身效率如何也未知。所以我們才會選擇使用更上層的封閉，一方面減少工作量，另一方面，避免無關的錯誤發生。從這一點出發，在做技術選型之時，綜合取捨，業務簡單但對效能極端要求的情境，可以直接用C語言和EPOLL，業務複雜度高工程較大的需求，可以選用JAVA語言和MINA2。還是那句千年不變的老話，永遠沒有最好的技術，只有用最適合的技術。別人說的永遠只是別人的經驗，自己動手嘗試證明得到的才是最真實的！

原文:http://rdc.gleasy.com/