今天偶然看到兩篇關於討論epoll與高性能問題的文章，文章均頗爲爭議，下面是兩篇文章和討論的地址：
http://guanzhongdaoke-gmail-com.iteye.com/blog/189005
http://bbs.linuxtone.org/thread-3164-1-1.html
針對第一篇文章裏面，作者提到：“需要注意的是，如果僅僅的採用epoll來處理網絡服務器的話，感覺性能不會提高太大，畢竟io的處理相對於epoll或者poll的檢測來說，時間消耗是比較多的。這個話說得可能比較的繞口，簡單說就是你每次的epoll_wait所花費的時間，相對於你得到事件後所作的read,write==花費的時間要少狠多”，首先我們要明確如下一點：
1) I/O多路複用技術，不管是select/poll也好，還是epoll也好，對於read/write和業務邏輯，不論採用什麼模型，這三者之間都不會有任何區別。那我們爲什麼說epoll好？說epoll好是相對於select和poll，而且其更好是源自於起事件通知機制，並不是epoll_wait所花費的時間與讀寫費時的比較。epoll因爲採用了回調通知機制，相比於select和epoll的現行掃描和頻繁的內存拷貝操作而高效。但epoll的高效也是有適用場景的，其更適合於hold大量連接，但連接並不是特別活躍的場景。相比於select、poll，由於epoll省卻了頻繁的線性掃描和內存拷貝，故而效率凸顯；但對於I/O頻繁（大量數據傳輸是否可認爲I/O頻繁呢？）場景，epoll或者說事件驅動的機制，其高效並不明顯
2)如上說明了epoll最被人稱道的高效的原因，那是在和select與poll的對比之下，現在討論忽略epoll和另外兩者的不同之處，I/O多路複用機制的高效根源。這三種機制，目的均在於減少對I/O操作的等待，使進程不被阻塞於I/O，更快的響應用戶請求，提高交互體驗。其實是將I/O分片，這種思想其實個人感覺有點操作系統時間片輪轉機制的影子，不過這裏是將I/O分片而不是CPU時間分片，將長耗時的I/O等待劃分爲多片，將I/O等待時間利用到響應用戶的時間上，增大併發度。
討論了I/O複用的好處，下一個爭議點是要不要在epoll(個人認爲select和poll也一樣)的同時使用多線程，反對意見者認爲多線程需要加鎖開銷和切換開銷，持支持意見這認爲多線程能增大吞吐並且用I/O複用實現異步實現高併發的方式編程複雜度很高不易控制。當然，也有認爲多線程的同步控制其編程複雜度也很高不易控制所以反對之。
對於這一塊，我也不能輕易下結論，或者這本來就是個見仁見智的問題。不過在此我想寫下一些我所理解或者想到的東西，做個參考，適當取捨，備忘。
I/O複用，將I/O等待分片，已可實現初步的高併發，我們說過，epoll在I/O不活躍的時候性能不錯，我們就假設這種場景，ok，現在已經夠高效了，其實epoll已經完成了自己的使命了，後端多線程單線程神馬的和epoll的關係不是特別大的說。
一，使用單核CPU，這時候用單線程和多線程的區別是什麼？優缺點分別是？
單核CPU爲什麼要使用多線程呢？可能是爲了利用CPU時間分片的好處增大交互體驗，對於本身的任務處理並不能加速，也有可能減少I/O等待所帶來的交互體驗差（此處我們已經通過epoll解決了這個問題，當然不排除還要使用磁盤I/O，其實也可能使用epoll突破）；但是這樣帶來的負面效果是線程切換所引起的開銷；當然還有可能存在加鎖的開銷
二，多核環境下，使用單線程多線程的區別？優缺點
很明顯，多核環境下的單線程，無法利用到多核優勢，此外，在多核環境下，如果線程設計合理，將任務均分到不同的核，可充分利用多核優勢，並且不會導致過多的線程切換帶來的性能開銷（因爲多核情況下，每個核擁有自己獨立的運行隊列，每個核上均存在自己的調度），此時單進程唯一的有點將是更少的鎖爭用
暫時想到的就這麼多……不知道準確否，至少在思考了