多进程解决datasnap支持的tcp长连接数量少的问题

对于实时采集数据的项目，应用场景比如是这样的：5000客户端，每个客户端每隔500MS要给服务器上传一次数据。

大家知道，像INDY这种阻塞型的通信控件，所能支持的TCP长连接的一般地不能超过1000的数量（如果想要维持稳定运行的话）。

原因是大家都晓得的，阻塞方式会为每一个SOCKET连接创建一个新的线程为之服务，而WINDOWS单个进程理论上允许最多的线程数量是2048个，

实际当中要少得多才行。

有人说可以用WINDOWS的IOCP通信模型解决，诚然！但IOCP编程过于复杂。

有人说，可以用INDY，使用短连接的方式解决。鉴于每隔500MS就要上传一次数据的频率，短连接其实不适合用，因为短连接每次都要建立和断开SOCKET连接，

而建立和断开SOCKET连接是特别耗时的，所以使用TCP长连接的方式。

有人说为什么想着阻塞的方式，答案是：因为阻塞的编程是最简单的。

其实对于5000长连接的客户端，INDY一样可以有办法实现。既然单个进程只能支持1000个左右的长连接，那开5个进程不是就可以支持5000个长连接了吗？

有人说，阻塞的5000个连接就意味着WINDOWS要开5000个线程，如此多的线程，WINDOWS受得了吗？

于是马上动手实验，一个进程开1500个线程，一共开了4个进程，每个线程每隔100ms,执行FOR I:=1 TO 100 DO，WINDOWS任务管理器显示，每一个进程

占用40.4M的内存，CPU使用率才百分之零点几，总的CPU使用率才百分之几，内存使用率也只有20%，WINDOWS调度没有一点儿问题。

这种方案只需要一个公网IP，分别为不同的进程绑定不同的端口。

多进程解决datasnap支持的tcp长连接数量少的问题