大并发量服务开发,select/poll模式与多进程/线程模式哪种更好??

GNM

目前正在做一个并发量在500/s左右的服务应用,现在有两种并发模式选择,一种是select/poll,另一种是多进程/线程池方式,不知哪种模式更强,在稳定性,可扩展性.....等方面好点???请大家讨论讨论

[ 本帖最后由 GNM 于 2007-7-19 23:29 编辑 ]

xhl

原帖由 GNM 于 2007-7-19 23:24 发表
目前正在做一个并发量在500/s的服务应用,现在有两种并发模式选择,一种是select/poll,另一种是多进程/多线程方式,不知哪种模式在稳定性,可扩展性.....等方面好点???请大家帮我定舵

一般就IO部分来讲， 500/S用SELECT/POLL单thread就可以了。

但如果你的应用逻辑比较复杂的话， 就要考虑结合多thread方式一起使用。

其实一般这两种模式都是结合使用的， 而不是简单的一个thread仅仅处理一条连接。

如果你写网络程序经验不是很多的话，建议用多进程或者多thread 一个thead处理一条连接方式，
因为这样可以确保一条连接出问题了， 不影响其他连接工作。 比稳定的select/poll更容易实现。

[ 本帖最后由 xhl 于 2007-7-19 23:34 编辑 ]

GNM

谢谢,如果从程序实现上来看,多线程更简单点,select方式看了一下好复杂,但如果性能比线程更好的话也是可取的.

hightman

原帖由 GNM 于 2007-7-19 23:56 发表
谢谢,如果从程序实现上来看,多线程更简单点,select方式看了一下好复杂,但如果性能比线程更好的话也是可取的.

ＩＯ多路复用的话要都得弄成无阻塞，但无阻塞有个麻烦就是无法真正确保一次读完想读的字节量．

比如某个ＳＯＣＫＥＴ上可读，预期读取８０００bytes，可能由于网络原因这一次只能读到４０００bytes，这里您必须针对这条连接建立cache，以便下次可读时合并处理．

converse

单进程+select+非阻塞对于LZ的应用应该够用了.
如果处理逻辑比较复杂,可以考虑预fork多进程+上面的网络模型进行处理.

caicaiqueenie

原帖由 converse 于 2007-7-20 09:31 发表
单进程+select+非阻塞对于LZ的应用应该够用了.
如果处理逻辑比较复杂,可以考虑预fork多进程+上面的网络模型进行处理.

个人认为:这种情况最好不要使用单进程+select+非阻塞这样的策略,采用这种策略一般需要非常好的编程功底,或者针对特定的应用而采用特定的程序架构,而且无阻塞型的I/O可能会造成忙等或者对CPU资源的低效利用.

楼主所采提到的情况,一般采用POSIX线程来进行处理,简介,高效,架构清晰,可移植性强,又有良好的扩展性.

cugb_cat

原帖由 caicaiqueenie 于 2007-7-20 09:59 发表

个人认为:这种情况最好不要使用单进程+select+非阻塞这样的策略,采用这种策略一般需要非常好的编程功底,或者针对特定的应用而采用特定的程序架构,而且无阻塞型的I/O可能会造成忙等或者对CPU资源的低效利用.
...

这种无阻塞IO不会造成忙等，还有select阻塞呢

converse

>>而且无阻塞型的I/O可能会造成忙等或者对CPU资源的低效利用

不知道这个观点是怎么得来的?如果某个client的网络条件不好,难道要一直阻塞在接收这个client的数据之上么?能不能详细说说看.

cugb_cat

500个连接/s的情况还不算大量，使用select的io多路复用已经够用了

hightman

原帖由 converse 于 2007-7-20 10:11 发表
>>而且无阻塞型的I/O可能会造成忙等或者对CPU资源的低效利用

不知道这个观点是怎么得来的?如果某个client的网络条件不好,难道要一直阻塞在接收这个client的数据之上么?能不能详细说说看.

select/poll 这种模型都是单进程轮循，每个时刻只能处理一个client，如果每次处理需要相当长时间（程序上的相当长时间，不知平时生活中的相当长时间），那么其它的就必须等待．

像聊天室服务器，一般client过来就是一句话，然后处理就是读出这句话广播给全部用户．．．．如果并发不多这种操作方式很节源．因为单程的话很多时候很省内存，也便于各client通信，采用多进程多线程就要考虑进程或线程之间的同步互斥．

其实无论用哪种都要看自己的需求分析，肯定没有绝对优势嘛，ＬＺ的问题关键在于client来干什么，各client之间是否经常要通信，每个client之间是否有大量的共有变量从这几方面考虑看看？