Test the forwarding strength of socket TCP high-density information broadcast

In some scenarios, a large number of message broadcast forwarding exists. net socket TCP performance in this regard, so a relatively extreme information broadcast forwarding strength test. the test scenario is to use 400 pieces of connection information to broadcast each other as a test case. When one connection sends a message to the server, it forwards the message to another connection, the test results show that each connection broadcasts 1600000 and 10 times per second, and the server forwards, and messages per second.

The tested hardware is a win2008 server, one win2003 server, and two VM win2003. the test interaction message is as follows:

 
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 );}}
 

The size of the above message writing stream is 18 bytes. Because MB exchange was used in the previous test, the total number of messages that ran about is basically full, I recently switched to MB, so I went into a intensive interaction test again.

Results sent twice per second

Results sent 5 times per second

Results sent 10 times per second

Summary

From the final test results, even if messages are forwarded to 1600000 messages per second, the CPU and internal usage are still very low.ProgramThe log output shows that about 27000 Io messages are used every second to process over million messages. Simply calculate that each Io processes more than 50 messages. due to the lack of I/O resources, this must also be done in the face of this situation, even if the Gigabit SwitchPPS is accessible only1488000 so we don't need to talk about it at the system software level.Although merge is used to process the forwarded data, the latency control is ideal. Even if the server's forwarding volume reaches 1600000 messages per second, each message can still be controlled within 20 ms to reach the client.

From the perspective of server resources, more extreme stress tests can be performed. However, the client is not powerful because the entire test process includes protocol analysis, and the object writing stream and stream are interpreted as objects, since an object on the server is distributed to N connections only once, the loss is not high. however, the client is different. Every time a message is received, it needs to be deserialized into an object. for low-configuration clients, it is not enough to process Message analysis and reverse sequences of nearly messages per second. If there is a better machine in the future, it will be tested in detail.

I believe that my friends who have read this test will apply this method. net socket has a deeper understanding, the same. net socket has excellent performance with the support of iocp.