提高select/poll的可擴展性設(shè)想求證

svenwang

在linux2.4內(nèi)核中不支持epoll，而傳統(tǒng)的select/poll的可擴展性(scalability)又比較差。我想，有沒有可能通過多線程來解決這個問題。比如如果有數(shù)千個連接，就可以每1000個連接在一個線程上使用select/poll實現(xiàn)I/O復(fù)用，當連接數(shù)增加的時候（達到硬件/OS處理極限之前），多創(chuàng)建線程就可以了。
不知道這個設(shè)想可不可行？

svenwang

自己頂一下

精簡指令

POLL本身就不受連接數(shù)的限制了。
用多線程的話，又多了線程之間的切換，好處不明顯啊。

svenwang

原帖由 "精簡指令" 發(fā)表：
POLL本身就不受連接數(shù)的限制了。
用多線程的話，又多了線程之間的切換，好處不明顯啊。

雖然poll對于管理的描述符的數(shù)目沒有限制，但是連接數(shù)目多的時候poll的性能就受到影響。

柳五隨風

對與這么大的壓力,我人為你可以選擇LOADＢＡＮＬＡＮＣＩＮＧ，單純的但ＰＲＯＣＥＳＳ無論采用什么技術(shù)，都不是完美的．
可以采用ＣＬＵＳＴＥＲ，或者ＮＡＴ／ＤＮＳ等算法實現(xiàn)負載均衡．

svenwang

原帖由 "柳五隨風" 發(fā)表：
對與這么大的壓力,我人為你可以選擇LOADＢＡＮＬＡＮＣＩＮＧ，單純的但ＰＲＯＣＥＳＳ無論采用什么技術(shù)，都不是完美的．
可以采用ＣＬＵＳＴＥＲ，或者ＮＡＴ／ＤＮＳ等算法實現(xiàn)負載均衡．

壓力也不算太大吧，希望能夠處理2000個連接，主要還是CPU 密集型
的服務(wù)器。cluster什么的成本太高了，也不用這么復(fù)雜。

柳五隨風

如果你這里的連接我理解正確的話
那么,無論你采用什么模型,都是大系統(tǒng),光OS在TCPBUFFER上的開銷就要32M~240M左右.更不要提FD數(shù)和PROCESS的調(diào)度問題了.加上DATA RESOURCE的問題,赫赫,好可怕

如果,你的意思是最大用戶數(shù)的話,那是有其他解決方法的.具體采用什么方式和你的系統(tǒng)性能需求,業(yè)務(wù)模型有很大關(guān)系.比如采用SINGLE PROCESS處理的話,那么你需要確認你的SERVICE處理的能力范圍,PIPELINE/STREAM LINE體系構(gòu)構(gòu),最大可能的并發(fā)程度等(比如BUFFER的構(gòu)成方式, BUFFER與SERVICES和NET地銜接方式等),這種模型成為APP緊偶合.
此外,還有一種方式,就是PROCESS GROUPS+PROCESSES+THREADS( SERVICES)的方式,松偶合的,可以再起前面加上一個REQUEST ALLOCATOR,負責DISPATCH請求(對等模式,實際上也是一種負載平衡的實現(xiàn)),不要也可以,那就需要其他機制還負責PROCESS GROUP的調(diào)度了,MASTER/SLAVE模式的DISPATCH方式.采用這種模型,在SOFTWARE層上解決了系統(tǒng)的動態(tài)伸縮問題,但是需要OS和HARDWARE層支持.

如果你真有2000個SESSION/CONNECTION的話,恐怕系統(tǒng)規(guī)模不小呢