(1)当系统负载较轻是,每来一个客户请求现场派生一个子进程为之服务的传统并发服务器程序模型就足够了。这个模型甚至能够与inetd结合使用,也就是inetd处理每一个链接的接收。咱们的其余意见是就重负荷运行的服务器而言的,譬如Web服务器。
编程
(2)相比传统的每一个客户fork一次设计示范,预先建立一个子进程池或一个线程池的设计示范可以把进程控制CPU时间下降10倍或以上。编写这些示范的程序并不复杂,不过以上没有给出例子的是:监视闲置子进程个数,随着所服务客户数的动态变化而增长或减小这个数目。
服务器
(3)某些实现容许多个子进程或线程阻塞在同一个accept调用中,另外一些实现却要求包绕accept调用安置某种类型的锁加以保护。文件上锁或pthread互斥锁上锁均可以使用。
网络
(4)让全部子进程或线程自行调用accept一般比让父进程或主线程独自调用accept并把描述符传递给子进程或线程来得简单而快速。
多线程
(5)因为潜在select冲突的缘由,让全部子进程或线程阻塞在同一个accept调用中比让他们阻塞在同一个select调用中更可取。<<UNIX网络编程——客户/服务器程序设计示范(三)>>有说明。
并发
(6)使用线程一般远快于使用进程。不过选择每一个客户一个子进程仍是每一个客户一个线程取决于操做系统提供什么支持,还可能取决于服务每一个客户需激活其余什么程序(如有其余程序需激活的话)。举例来讲,若是accept客户链接的服务器调用fork和exec(譬如说inetd超级守护进程),那么fork一个单线程的进程可能快于fork一个多线程的进程。spa