测试环境
  两台笔记本网线直连,通过测速工具(jperf)测试,确定两台电脑之间的数据传输速度可以达到1Gbps,即千兆网卡的大速度。两台电脑硬件配置如下:
  client服务器,CPU:Intel i5-3230 2.6GHz    内存:8G
  server服务器,CPU:Intel i5-3210 2.5GHz  内存:4G
  ENode使用的通信层(有兴趣的可以下载ECommon的源代码,运行代码中的Remoting的Sample),支持Oneway, Async, Sync三种通信模式。
  Oneway表示client将数据通过socket发送后不关心server的处理结果,这种模式类似于Push-Pull的通信方式;
  Async表示client将数据发送到server后异步等待server的处理结果;
  Sync表示client将数据发送到server后同步等待server的处理结果;
  由于Sync的方式效率较低,且因为ENode中使用通信层只会用到Oneway和Async两种方式;所以我只测试了Oneway, Async这两种通信模式。
  测试结果
  Oneway

  说明:
  理论上如果两台电脑之间的带宽是千兆,即1Gbps,即125MB的话,那假设一个消息大小是1KB,那如果发送者和接收者的CPU和内存不会成为瓶颈,那理论上每秒应该可以发送接收125 * 1024 = 128000/s。
  关于客户端数量是指在client机器上开几个进程进行发送消息,目前我是一个进程一个TCP连接。
  大家可以看到,当消息大小为1K时,客户端机器4个进程同时发送,服务端机器全部接收完用时39.5s,也是每秒101265接近网卡的极限。为什么没有达到网卡的极限,其实可以到达只要我开6个进程发送消息即可。只是我上面为了方便对比,每个消息大小多开4个进程。
  测试过程中,我发现客户端向服务端发送数据的吞吐量,主要的瓶颈还是在CPU。如果CPU好,那发送速度会很快,直到把网卡压满位置。
  在消息大小为2K时,我没有测试4个进程同时发送消息的场景,因为内存不够用了。
  Async

  说明:
  大家可以看到Async的通信模式,性能下降很多。是因为Async要比Oneway的方式,在逻辑上要多很多逻辑。比如发送前要先把一个TaskCompletionSource加入到一个ConcurrentDictionary中,然后当对应的RemotingRequest有回复时,获取到对应的TaskCompletionSource,然后设置回复结果,从而让发送数据的Task完成。以此实现异步发送数据的过程。
  测试Async的过程中,我发现假如瞬间假如100W个TaskCompletionSource到ConcurrentDictionary,然后通过Socket进行异步发送数据,一开始CPU会压力非常大;所以我为了降低CPU的瓶颈,让每个客户端只发送50W数据;
  从上面的测试结果可以看出,1K大小的数据,Async模式发送,吞吐量大在3.3W。经过我的分析,主要的瓶颈还是在CPU。因为此时CPU基本接近极限,而网卡只跑了250MB左右。说明我们应该尽量优化CPU的利用率,减少并发冲突。将来我准备使用Disruptor.Net来尝试看看是否能提高Async模式的性能。
  在消息大小在1K和2K的情况下,我没有测试客户端数量为4的情况,因为此时Client端机器的CPU,内存都已经成为瓶颈,没必要测试了。实际上,在客户端进程数量在3的时候,也已经成为瓶颈。
  关于阿里云ECS的测试计划
  接下来准备再阿里云ECS服务器上再做一下类似的测试,之前简单摸底了一下。购买了两台ECS虚拟机,配置都是4核8G内存。通过内网IP进行TCP测试(使用jperf工具)。发现两台虚拟机之间,大只能达到60MB的速度。这说明,阿里云的ECS服务器之间,带宽无法达到125MB,比较遗憾。但这也是我未来希望部署ENode案例的真实服务器,所以在这个环境上的测试结果,应该更具参考价值。
  未来的测试计划
  大概知道通信层的性能之后,我准备对EQueue发送消息和接收做性能测试。这个测试结果,是决定ENode各个节点之间,消息传递吞吐量的主要依据。