测试环境
　　两台笔记本网线直连，通过测速工具（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各个节点之间，消息传递吞吐量的主要依据。