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

hightman

大量并发，可以参考apache的worker那种模型

cugb_cat

原帖由 hightman 于 2007-7-20 10:16 发表


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

像聊天室服务器，一般cli ...

恩，现在流行的epoll+线程池也是针对短连接的

福瑞哈哥

能否采用select模式关键在于对每一个client端的响应是否是会在某一点阻塞，如果有耗时操作，为了简单你可以使用多线程／多进程。不过我遇到这种情况，都是把耗时操作另外fork进程处理，与主服务进程通过pipe连接。

GNM

谢谢大家,我这个应用逻辑比较简单,就是先将后台数据(>G),mmap进内存里,然后通过client相应请求返回内存中相应关键字，,内存消耗可以不用考虑。
   听大家这么说，select和多线程都能满足需求，但考虑到多CPU多核处理，及性能上，是不是线程池模式更好点？？当然了，apache的workers模型就更无敌了：进程池+线程池+poll。。。但实现起来太复杂。

福瑞哈哥

原帖由 GNM 于 2007-7-20 10:31 发表
谢谢大家,我这个应用逻辑比较简单,就是先将后台数据(>G),mmap进内存里,然后通过client相应请求返回内存中相应关键字，,内存消耗可以不用考虑。
   听大家这么说，select和多线程都能满足需求，但考虑到多CPU多 ...

都可以了，本身好像并无太多cpu操作，占用率本身就很低，多cpu用不上啊。

qilikacha

原帖由 cugb_cat 于 2007-7-20 10:10 发表

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

看LZ的功底了，都行的

caicaiqueenie

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

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

多处对套接字句柄的扫描处理，这个肯定会影响效率.有n次调用,发生数据交换的次数可能远远n,存在着CPU资源的低效利用.

http://linux.chinaitlab.com/kernel/527653_2.html

这里有个相关的连接,里面描述的比较清晰.

我认为最好使用线程进行编写.

福瑞哈哥

原帖由 caicaiqueenie 于 2007-7-20 13:17 发表



多处对套接字句柄的扫描处理，这个肯定会影响效率.有n次调用,发生数据交换的次数可能远远n,存在着CPU资源的低效利用.

http://linux.chinaitlab.com/kernel/527653_2.html

这里有个相关的连接,里面描 ...

同版主疑问，不明白为什么说select模式效率低。就我的理解，这样的网络通讯程序的瓶颈是在通讯又不是在cpu。

caicaiqueenie

原帖由 福瑞哈哥 于 2007-7-20 13:23 发表

同版主疑问，不明白为什么说select模式效率低。就我的理解，这样的网络通讯程序的瓶颈是在通讯又不是在cpu。

我也认为通讯的瓶颈不在CPU,但是select确实浪费了CPU,而且select的描述符集的数量好像还有限制.
我一般不使用select模式进行类似程序处理.

converse

原帖由 caicaiqueenie 于 2007-7-20 13:47 发表



我也认为通讯的瓶颈不在CPU,但是select确实浪费了CPU,而且select的描述符集的数量好像还有限制.
我一般不使用select模式进行类似程序处理.

select耗CPU这个我也知道,因为select每次都要把描述字set中的fd轮询一次,如果系统版本够高可以考虑用epoll代替,我的想法是这些多路复用的API用其中一个就好了.

如果你不用select你准备怎么做呢?