昨天花了大量時間在“調優”：因為伺服器的網絡輸出帶寬死活與計算值不符合。理論判斷網絡輸出帶寬應該是90Mbps，但是檢測卻隻有50+Mbps而已。做了幾個試驗後，我們覺得是伺服器性能問題，于是祭出profile殺器，可是優化了幾個耗時多的函數後，帶寬巍然不動。之後我們先xxoo，再 ooxx，搞得是雞飛狗跳，最後發現一方面是由于我們被帶寬顯示工具誤導了，另一方面當udp包較小的時候，并不是所有網絡帶寬都可使用。
1）我們在Linux主機用“iftop -i eth0”檢視網絡帶寬，iftop顯示的情況極其詳盡，但是它會影響可用帶寬!!!當我們關掉iftop程序後，主機的輸出帶寬立馬從50+Mbps上升到80Mbps。是以iftop适合在發現帶寬與理論不一緻的時候用來檢視是否有其他連接配接在使用帶寬。平時顯示帶寬用“watch -n 1 "vnstat -tr 2"”。 windows下直接用任務管理器，檢視“聯網”頁籤即可。
2）當udp包較小的時候，沒辦法充分使用所有帶寬。下表兩台主機都使用100M網卡接入100M區域網路。表中第一行表示使用Linux主機發送，Windows主機接收；第二行表示使用Windows發送，Linux主機接收。帶寬并不是确定不變的，表中的數值隻是近似值。左邊表示發送方的帶寬統計，右邊表示接收方的帶寬統計,如果基本一緻則隻列出一項。帶寬機關均是bps。
udp包長度（不含udp頭） 5B 10B 20B 40B 80B 160B 320B 640B 1280B
Linux發送 47M/60M 51.2/60M 62M 73.5M 80M 86M 91M 95M 97M
Windows發送 41M/40M 50/43M 70M/54M 76M/62M 80M/71M 86M/80M 92M/87M 96M/91M 97M/93M
發送帶寬和接收帶寬不一緻主要有幾個原因：帶寬統計工具不是十分精确；較小的包會填充到最小長度(46-8-20=18)；還有就是區域網路内也是會丢包的。下表列出了每秒發送/接收的包的數目。不過我已經得到我想知道的東西了，是以隻是随便測試幾項哈哈：）
udp包長度（不含udp頭） 10B 40B 160B 640B
Linux發送 126657/125695 114086/113607 54128/53686 17560/17437
Windows發送 114824/114636 116841/116388 55235/55191 17542/17525
收發包率的差别要比帶寬來得小。這也說明了我們使用的帶寬統計工具不是十分精确。（收發包的數目在程式中統計，是準确的）
3) 當目标主機是windows時，如果沒有程序接收udp資料，對資料發送是有影響的。因為windows會對每個udp包響應一個“端口不可達”的 ICMP包。這個包在我機器上是90位元組(720bits)。比如udp size=320時，Linux=>Windows：如果windows有程序接收的話，windows入口帶寬大概是91M，出口為0；如果 windows沒有程序接收，入口帶寬則隻有50多M，出口帶寬則有30多M。
===================華麗的分割線=====================
結論：如果要充分利用帶寬資源，udp包的平均長度不能太小。在測試環境下，160B位元組的udp包大概可以利用86%的理論帶寬，640B則可以利用到93%+。當然，這隻是在兩台主機上的測試結論。如果網卡或者機器更牛x，估計還是有上升空間的。
===================2010-12-27=====================
今天再次運作該程式，發現測試小包時的結果有誤：那個瓶頸是CPU造成的，而不是網卡IO造成的。在多核機器上通過多開程序的方式可以提高小包時的可用帶寬。但如果單程序時CPU使用率本就不滿的時候，提高程序數是沒有用的。比如通過多開程序，linux發送10B可以達到58Mbps而不是上表中的51.2Mbps，udp包長大于30時，多開程序不起效果。至于windows，由于現在硬體很強，單程序直接就可以到58Mbps了，cpu未滿，提高程序數也不起效果。最新的測試結果（40B以上沒有變化，不列出來，windows和linux差别不大，故隻列一行）
udp包長度（不含udp頭） 5B 10B 20B
52.8M 58.42M 68.1M
![c++運算符重載練習[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)