|
我們先來介紹下nginx nginx : 支持高并發(fā)連接．官方測試的是５ｗ并發(fā)連接但在實際生產(chǎn)中可制成2-4w并發(fā)連接數(shù),得益于nginx使用最新的epoll(linux 2.6內(nèi)核)和kqueue(freebsd)網(wǎng)絡(luò)I/O模型.而apache使用的則是傳統(tǒng)的select模型,其比較穩(wěn)定的prefork模式為多進程模式,需要經(jīng)常派生子進程,所消耗的CPU等服務(wù)器資源要比nginx高的多. select 和epoll效率差的原因: select是輪詢、epoll是觸發(fā)式的，所以效率高。單單這樣講,那能懂了才見鬼了.好...我們暫且客觀的記住這句話. 先說Select: 1.Socket數(shù)量限制:該模式可操作的Socket數(shù)由FD_SETSIZE決定,內(nèi)核默認32*32=1024. 2.操作限制:通過遍歷FD_SETSIZE(1024)個Socket來完成調(diào)度,不管哪個Socket是活躍的,都遍歷一遍. 后說Poll: 1.Socket數(shù)量幾乎無限制:該模式下的Socket對應(yīng)的fd列表由一個數(shù)組來保存,大小不限(默認4k). 2.操作限制:同Select. 再說:Epoll: 1.Socket數(shù)量無限制:同Poll 2.操作無限制:基于內(nèi)核提供的反射模式,有活躍Socket時,內(nèi)核訪問該Socket的callback,不需要遍歷輪詢. 但是當所有Socket都活躍的時候,這時候所有的callback都被喚醒,會導(dǎo)致資源的競爭.既然都是要處理所有的Socket,那么遍歷是最簡單最有效的實現(xiàn)方式. 舉例來說: 對于IM服務(wù)器,服務(wù)器和服務(wù)器之間都是長鏈接,但數(shù)量不多,一般一臺60\70個,比如采用ICE這種架構(gòu)設(shè)計,但請求相當頻繁和密集,這時候通過反射喚醒callback不一定比用select去遍歷處理更好. 對于web portal(門戶)服務(wù)器,都是瀏覽器客戶端發(fā)起的http短鏈接請求,數(shù)量很大,好一點的網(wǎng)站動輒每分鐘上千個請求過來,同時服務(wù)器端還有更多的閑置等待超時的Socket,這時候沒必要把全部的Socket都遍歷處理,因為那些等待超時的請求是大多數(shù)的,這樣用Epoll會更好. 支持一個進程打開大數(shù)目的socket描述符 select 最不能忍受的是一個進程所打開的FD是有一定限制的，由FD_SETSIZE設(shè)置，默認值是1024。對于那些需要支持的上萬連接數(shù)目的IM服務(wù)器來說顯然太少了。這時候你一是可以選擇修改這個宏然后重新編譯內(nèi)核，不過資料也同時指出這樣會帶來網(wǎng)絡(luò)效率的下降，二是可以選擇多進程的解決方案（傳統(tǒng)的 Apache方案），不過雖然linux上面創(chuàng)建進程的代價比較小，但仍舊是不可忽視的，加上進程間數(shù)據(jù)同步遠 比不上線程間同步的高效，所以也不是一種完美的方案。不過 epoll則沒有這個限制，它所支持的FD上限是最大可以打開文件的數(shù)目，這個數(shù)字一般遠大于2048,舉個例子，在1GB內(nèi)存的機器上大約是10萬左右，具體數(shù)目可以cat /proc/sys/fs/file-max察看，一般來說這個數(shù)目和系統(tǒng)內(nèi)存關(guān)系很大。 IO效率不隨FD數(shù)目增加而線性下降 傳統(tǒng)的select/poll另一個致命弱點就是當你擁有一個很大的socket集合，不過由于網(wǎng)絡(luò)延時， 任一時間只有部分的socket是“活躍”的，但是select/poll每次調(diào)用都會線性掃描全部的集合，導(dǎo)致效率呈現(xiàn)線性下降。但是epoll不存在這個問題，它只會對“活躍”的socket進行操作---這是因為在內(nèi)核實現(xiàn)中epoll是根據(jù)每個fd上面的callback函數(shù)實現(xiàn)的。那么，只有“活躍”的socket才會主動的去調(diào)用 callback函數(shù)，其他idle狀態(tài)socket則不會，在這點上，epoll實現(xiàn)了一個“偽”AIO，因為這時候推動力在os內(nèi)核。在一些 benchmark中，如果所有的socket基本上都是活躍的---比如一個高速LAN環(huán)境，epoll并不比select/poll有什么效率，相反，如果過多使用epoll_ctl,效率相比還有稍微的下降。但是一旦使用idle connections模擬WAN環(huán)境，epoll的效率就遠在select/poll之上了。 使用mmap加速內(nèi)核與用戶空間的消息傳遞。 這點實際上涉及到epoll的具體實現(xiàn)了。無論是select,poll還是epoll都需要內(nèi)核把FD消息通知給用戶空間，如何避免不必要的內(nèi)存拷貝就很重要，在這點上，epoll是通過內(nèi)核于用戶空間mmap同一塊內(nèi)存實現(xiàn)的。而如果你想我一樣從2.5內(nèi)核就關(guān)注epoll的話，一定不會忘記手工 mmap這一步的。 內(nèi)核微調(diào) 這一點其實不算epoll的優(yōu)點了，而是整個linux平臺的優(yōu)點。也許你可以懷疑linux平臺，但是你無法回避linux平臺賦予你微調(diào)內(nèi)核的能力。比如，內(nèi)核TCP/IP協(xié)議棧 使用內(nèi)存池管理sk_buff結(jié)構(gòu)，那么可以在運行時期動態(tài)調(diào)整這個內(nèi)存pool（skb_head_pool）的大小--- 通過echo XXXX>/proc/sys/net/core/hot_list_length完成。再比如listen函數(shù)的第2個參數(shù)（TCP完成3次握手 的數(shù)據(jù)包隊列長度），也可以根據(jù)你平臺內(nèi)存大小動態(tài)調(diào)整。更甚至在一個數(shù)據(jù)包面數(shù)目巨大但同時每個數(shù)據(jù)包本身大小卻很小的特殊系統(tǒng)上嘗試最新的NAPI網(wǎng) 卡驅(qū)動架構(gòu)。 select模式低效的原因 select 模式低效是由select的定義所決定的，與操作系統(tǒng)實現(xiàn)無關(guān)，任何內(nèi)核在實現(xiàn)select時必須做輪循，才能知道這些socket的情況，這是會消耗 cpu的。此外，當你擁有一個很大socket集的時候，盡管任一時間只有小部分的socket是"活躍"的，但每次你都不得不將所有的socket填入到一個FD_SET中，這也會消耗一些cpu，并且當select返回后，處理業(yè)務(wù)時你可能還需要做“上下文映射”，同樣也會有一些性能影響，因此 select比epoll相對低效。 epoll的適用情景就是大量的socket，但是活躍多不是很高的情況。 還有 kqueue，實際上有不少服務(wù)器是基于 BSD 開發(fā)的。 http:///bencandy.php?fid=54&id=1129 |
|
|
