注意，題目不是「傳說中」的epoll。epoll我親自用過，自然不是傳說，但下文中的效能分析，皆為道聽途說，並不是親自做的實驗。
這年頭做網路併發模型的，如果說沒用過epoll，八成是要遭人鄙視的。那麼，epoll的效能到底有多好？
先看下面這張圖， link：
但凡學過epoll的人都看過這樣類似的圖。圖的縱軸是每秒的http響應數，其實就是系統的吞吐量（throughput），橫軸則是併發的連線數。很明顯，epoll的效能要遠好於傳統的poll，在整個橫軸範圍內，無論併發的連線數是多少，epoll都保持了穩定的吞吐量。這也是為什麼我們要選擇epoll的原因。因為它能夠支援海量併發連線，它能夠解決c10k problem 。
（epoll和poll的差別在很多地方都找得到，簡而言之，傳統的select/poll對於監聽的socket採取輪詢的方式，每次輪詢都要線性檢視所有的socket；而epoll的優點是它每次只對活躍的socket進行操作）
如果只是到此為止，那麼可能所有的人都會認為，epoll代表著先進的生產力，我們應該摒棄poll而擁護epoll（很多初學者如我一開始都是這麼想的）。
別急，再來看另乙個實驗：link：
圖的縱軸表示的是epoll比poll速度的比例（這裡有些不清楚，「faster」這個詞到底是指什麼？throughput？latency？）。而橫軸很有意思，它表示的是監聽的所有socket中active（活躍數）和total（總數）的比。舉例說，有一千個使用者同時連線到了系統，這時候total就是1000，但是，這一千個使用者中只有乙個使用者在傳送請求，那麼active的值就是1。整個圖所表示的意思是，如果active/total的比值很小，那麼epoll要比poll快好幾倍（圖的左側），但是，如果active/total的值比較大（接近1），那麼，epoll的效能可能和poll沒有太大差別，甚至更差（圖的右側）。而這篇文章的作者得到乙個經驗的臨界值：當active/total為0.6時，兩者效能幾乎相等。
結論是不是出乎意料？其實細想一下，也很好理解。當active/total的值很小的時候，說明活躍的連線數不多，這時候poll仍然要輪詢所有的連線，而epoll只需要處理活躍的那部分。可是，當active/total的值接近1的時候，這時候大部分連線都是活躍的，poll的輪詢命中率會很高，而epoll的優勢相應的就不明顯了。
所以，即便是epoll和poll，也很難說其中的乙個就一定比另乙個好。那麼，對於其它的一些併發模型，比如multi-thread，比如thread pool，就更難分出個絕對的勝負了。每乙個都有適合的應用場景。
傳說中的MTU
通訊術語 最大傳輸單元 maximum transmission unit，mtu 是指一種通訊協議的某一層上面所能通過的最大資料報大小 以位元組為單位 最大傳輸單元這個引數通常與通訊介面有關 網路介面卡 串列埠等 網際網路協議允許ip分片，這樣就可以將資料報分成足夠小的片段以通過那些最大傳輸單元小...
傳說中的truncate html
學習用rails做blog的時候要用到rails的truncate功能。h truncate post.content,100,問題來了，將html截斷後出現不完整的tag，導致後續的文章排版都錯亂了。本來考慮是不是自己寫乙個，正在思考思路，結果祭起google，好嗎，已經有牛人寫了 簡單記錄一下 ...
傳說中的分頁6
set quoted identifier off goset ansi nulls on go 名稱 分頁儲存過程 使用示例 exec sp pageindex from stusources 2,10 注意 目前還沒有對輸入的引數進行嚴格的驗證 預設為輸入都是合法有效的 alter proc s...