(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