提高select/poll的可扩展性设想求证

svenwang

在linux2.4内核中不支持epoll，而传统的select/poll的可扩展性(scalability)又比较差。我想，有没有可能通过多线程来解决这个问题。比如如果有数千个连接，就可以每1000个连接在一个线程上使用select/poll实现I/O复用，当连接数增加的时候（达到硬件/OS处理极限之前），多创建线程就可以了。
不知道这个设想可不可行？

svenwang

自己顶一下

精简指令

POLL本身就不受连接数的限制了。
用多线程的话，又多了线程之间的切换，好处不明显啊。

svenwang

原帖由 "精简指令" 发表：
POLL本身就不受连接数的限制了。
用多线程的话，又多了线程之间的切换，好处不明显啊。

虽然poll对于管理的描述符的数目没有限制，但是连接数目多的时候poll的性能就受到影响。

柳五随风

对与这么大的压力,我人为你可以选择LOADＢＡＮＬＡＮＣＩＮＧ，单纯的但ＰＲＯＣＥＳＳ无论采用什么技术，都不是完美的．
可以采用ＣＬＵＳＴＥＲ，或者ＮＡＴ／ＤＮＳ等算法实现负载均衡．

svenwang

原帖由 "柳五随风" 发表：
对与这么大的压力,我人为你可以选择LOADＢＡＮＬＡＮＣＩＮＧ，单纯的但ＰＲＯＣＥＳＳ无论采用什么技术，都不是完美的．
可以采用ＣＬＵＳＴＥＲ，或者ＮＡＴ／ＤＮＳ等算法实现负载均衡．

压力也不算太大吧，希望能够处理2000个连接，主要还是CPU 密集型
的服务器。cluster什么的成本太高了，也不用这么复杂。

柳五随风

如果你这里的连接我理解正确的话
那么,无论你采用什么模型,都是大系统,光OS在TCPBUFFER上的开销就要32M~240M左右.更不要提FD数和PROCESS的调度问题了.加上DATA RESOURCE的问题,赫赫,好可怕

如果,你的意思是最大用户数的话,那是有其他解决方法的.具体采用什么方式和你的系统性能需求,业务模型有很大关系.比如采用SINGLE PROCESS处理的话,那么你需要确认你的SERVICE处理的能力范围,PIPELINE/STREAM LINE体系构构,最大可能的并发程度等(比如BUFFER的构成方式, BUFFER与SERVICES和NET地衔接方式等),这种模型成为APP紧偶合.
此外,还有一种方式,就是PROCESS GROUPS+PROCESSES+THREADS( SERVICES)的方式,松偶合的,可以再起前面加上一个REQUEST ALLOCATOR,负责DISPATCH请求(对等模式,实际上也是一种负载平衡的实现),不要也可以,那就需要其他机制还负责PROCESS GROUP的调度了,MASTER/SLAVE模式的DISPATCH方式.采用这种模型,在SOFTWARE层上解决了系统的动态伸缩问题,但是需要OS和HARDWARE层支持.

如果你真有2000个SESSION/CONNECTION的话,恐怕系统规模不小呢