本实验用于测试ESFramework网络通信框架服务端引擎的性能，测试程序使用ESFramework 4.0版本。
一．准备工作
测试的机器总共有3台，都是普通的PC，一台作为服务器，两台作为客户端。
作为服务器是PC配置如下：
操作系统：Windows Server 2003 Enterprise Edition SP2
CPU：Pentium Dual-Core CPU E5400 @ 2.70GHz
内存：2G
二．测试策略
本实验所采用的策略是这样的：
（1）每个客户端实例首先与服务器建立N个TCP连接，然后依次在每个TCP连接上发送一个36字节的消息。遍历一次完毕后，等待（Sleep）M毫秒，再进行下一轮遍历发送。
（2）服务端接收到消息后，解析消息，然后累加消息的个数。
（3）客户端统计已发消息的总数，并计算上一秒发送的请求数。
（4）服务端统计已接收消息的总数，并计算上一秒接收的请求数。
三．测试过程
1．测试方案一：连接总数3000，每轮发送间隔100ms
（1）在作为服务器的PC上启动服务端。
（2）在作为客户端的两台PC上分别运行一个客户端实例。每个客户端实例设定连接数1500，每轮发送的间隔为100。
（3）如此，服务端的总的连接数为3000，以下是运行一段时间后的截图：
在该测试过程中，服务端的每秒处理的消息数量在26000 ~30000之间波动，而CPU持续在80%以上。
另外，在客户端的PC上通过NetLimitter可以看到每个连接上发出的数据流量：
2．测试方案二：连接总数6000，每轮发送间隔300ms
将方案一启动的各程序全部关掉，重头再来一次。
（1）在作为服务器的PC上启动服务端。
（2）在作为客户端的两台PC上分别运行一个客户端实例。每个客户端实例设定连接数3000，每轮发送的间隔为400。
（3）如此，服务端的总的连接数为6000，以下是运行一段时间后的截图：
在该测试过程中，服务端的每秒处理的消息数量在14000 ~18000之间波动，而CPU持续在65%以上。
四．测试结论
除此两种方案的测试以外，我们还进行了其它方案的测试，比如设置更小的连接数和更小的发送间隔，或设置更大的连接数和更大的发送间隔。测试反映，这台作为服务器的PC能承载的最佳并发连接数在4000左右，此时，服务器的吞吐量可以达到最大（每秒处理30000个左右的消息）。当连接数进一步增加时，吞吐量会降下来。最佳并发连接数和最大吞吐量的值与服务器机器的配置密切相关。
五．测试程序
本文末会提供测试程序的压缩包下载。在压缩包内附带了测试的服务端和客户端程序，有兴趣的朋友可以在自己的服务器上做更多的策略测试。在自己运行测试时，要注意以下几点：
（1）服务端最好运行在一台单独的机器上。如果客户端也运行在服务端所在的机器上，则会严重地影响服务端的吞吐量。
（2）合理地设置客户端的连接数和发送时间间隔。
（3）客户端运行的机器的操作系统对tcp连接数可能有最大值限制（有的是三千多），如果遇到这种系统，而单个客户端实例的连接数的设定又大于这个限制值，则会导致后续的tcp连接失败。若发生这种情况，请关闭客户端并重启，然后设定较小的连接数，再次测试。可以多开几个客户端实例，来增加连接数。
（4）如果服务器上有防火墙软件，可能会影响测试结果，最好关闭服务器上的防火墙进行测试。
任何问题，请联系sky.zhuwei@163.com。
敬请了解：
ESFramework通信框架 OMCS网络语音视频框架 MFile语音视频录制组件 MCapture语音视频采集组件 StriveEngine轻量级通信引擎 OAUS 自动升级系统