Socket Tcp高密集信息廣播轉發強度測試

在有些場中存在着大量的消息廣播轉發,為了了解.net socket tcp在這方面的性能表現,所以做了一個比較極端信息廣播轉發強度測試.測試場景是以400個連接信息相互廣播為測試用例就是當其中一個連接發送消息到服務端就會轉發到其他連接上,測試情況分別是每個連接每秒廣播2,5和10次,其服務器每秒的信息轉發量分別320000,800000和1600000.

測試的硬件分別是一台win2008服務器,1台WIN2003和兩個vm win2003.測試交互的消息如下:

class Po : IMessage
    {
        public int ID;
        public short X;
        public short Y;
        public short Type;
        public void Load(BufferReader reader)
        {
            ID = reader.ReadInt32();
            X = reader.ReadInt16();
            Y = reader.ReadInt16();
            Type = reader.ReadInt16();
        }
        public void Save(BufferWriter writer)
        {
            writer.Write(ID);
            writer.Write(X);
            writer.Write(Y);
            writer.Write(Type);
        }
    }

以上消息寫入流的大小是18個byte,由於在之前的測試中使用的是100mb交換,所以大概跑到50w左右的消息量基本就跑滿了,最近剛換上了1000mb交換所以重新進一個密集交互測試.

每秒發兩次的結果

每秒發5次的結果

每秒發10次的結果

總結

從最終的測試結果來看即使每秒轉發到到1600000消息,cpu和內在的使用率都還是很低的,從測試程序的日志輸出來看每秒大概使用了27000個IO來處理這1百多W的消息轉發,簡單地算一下大概每個IO處理了50多個消息.由於IO資源的缺少在面對這情況下也必須這樣做,即使千兆的交換機其pps也只通達到1488000因此到系統軟件層面就更不用談了.雖然使用了合並處理轉發數據,但延時控制還是很理想即使服務器的轉發量達到每秒1600000消息,但每個消息到達client還是可以控制到20ms內.

從服務器的資源來看其實還可以做更極端的壓力測試,可是client不給力因為整個測試過程包括協議分析,對象寫入流和流解釋成對象,由於服務端一個對象分發到N個連接也只是序列化一次,所以損耗並不高.但對於client就不一樣,每次接收一個消息都需反序列成對象.對於配置不高的client來說每秒要處理接近百W的消息分析和反序列完全應付不過來,如果以后有更好的機器會再詳細測一次.

相信看完這個測試的朋友應用對.net socket有更深入的了解,同樣.net socket在iocp的支持下其性能也是很出色的.