在有些场中存在着大量的消息广播转发,为了了解.net socket tcp在这方面的性能表现,所以做了一个比较极端信息广播转发强度测试.测试场景是以400个连接信息相互广播为测试用例就是当其中一个连接发送消息到服务端就会转发到其他连接上,测试情况分别是每个连接每秒广播2,5和10次,其服务器每秒的信息转发量分别320000,800000和1600000.
测试的硬件分别是一台win2008服务器,1台WIN2003和两个vm win2003.测试交互的消息如下:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
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的支持下其性能也是很出色的.