论UDX并发，单台服务器1.5w联接，每条联接发送1KB数据，10秒内没处理，断开联接--之改进过程

      对于并发这个话题已经讨论很多，特别是在TCP大量联接的成功案例很多。这里不例举，少说几W多则上10W都有。

     但是作为UDP可靠传输协议来说，每个事务处理都需要我们的CPU完成，而且我们要维护心跳，保证条条连接能正常收发，不让洞给关掉了，使联接断开。所以UDP的多条连接并发显得格外的重要了。因为要利用UDX的实时性，高吞吐量，必须达到可用的目的。否则传输性能再高，也没有什么太大的应用空间。比如在视频监控的流媒体服务器处理上，这种高并发显得就非常重要。而如果没有并发，则只能用在点对点之间传输音视频或文件，不能大规模的替换TCP的一般场景。

      UDX的传输的优势，包括实时性，吞吐量，跨平台，这些是牺牲了大量的CPU处理时间换来的，为了能快速的回发ACK及OnTimer回调，所以必须需要精确定时器。

为此UDX目前采用了多媒体定时器，及多线程，并没有使用IOCP,EPOLL,主要是考虑跨平台的简单特性，使用上轻量级。可以定制，内部工作线程数量。

但是精确定时器的存在，比如，50MS我们需要轮询一下，一条连接的消息通道和数据通道。1秒的时候，一条连接要处理 20 * 2 = 40次。而发送模块是精确到1MS级别的，那么，一条连接就是要处理接近 40*1000 = 4w次。

最近有个客户要求3W联接在线，并收发数据要求，为了争取一个客户我开始了优化过程，其实我心里明白的很，这是不可完成的任务，因为

以前面计算来看，如果，我们现在有1.5w条连接，就是1.5w*4w次处理。这对并发处理提出了很高的要求，但是这么大并发测试，根本没有过，我最多测试过2000.

我开始写测试用例，用例代码可以在我的网站www.goodudx.com上下载到.用这个测试用例可以在我的机器上跑4000联接。

本以为4000联接已经非常好了。但是现在不得不重新查找，每一个可能柱塞并发的地方。

客户找来一台AMD的服务器，2.4G主频，24核CPU，我开始了测试，8000并发，各个CPU，占用都很平均，就是连接量上不去。

在1.98版本之前，我测式发，较差的机器，可以并发在2000条连接，实时性不受影响，这里还只是一条连接只发送1KB/S.

在较好的机器上可以跑到4000条，比如我的现在I7 CPU 16G内存的机器中，不过主要是受CPU影响，理论上还要多一点点。

在客户LINUX64位服务器上测试，4000能稳定收发，8000时，有部分联接会因为得不到处理，联接超时断开。

回家思考，对联接管理，论轮采用分片式锁定，定时器采用属性计数方式。在处理数据时采用引用计数方式，防止锁的范围过大。尽量并发使用各个CPU，测试一举通过。

支持这么多联接以后，结合UDX的可定制，跨平台的特性，就完全可以在移动互联网领域，流媒体方案中及大型即时通讯产品，云存储，云计算中充份利用，前景一片光明。

希望更多的人来观注UDX,支持国产软件。