[換個(gè)地方發(fā)]請(qǐng)教大牛：異步io的優(yōu)點(diǎn)究竟在哪

xxxxxxxp

回復(fù) 70# starwing83

可能沒說清楚，場(chǎng)景A指處理線程收到請(qǐng)求后sleep 5ms后回復(fù)請(qǐng)求，場(chǎng)景B指處理線程收到請(qǐng)求后sleep 40ms后回復(fù)請(qǐng)求。連接數(shù)？客戶端向服務(wù)端按一定速度發(fā)短連接請(qǐng)求，連接數(shù)可以推出來
   

starwing83

回復(fù) 51# xxxxxxxp


    不太明白第二個(gè)同步樣例里面的cs和中斷數(shù)啥意思。中斷數(shù)是指的被系統(tǒng)調(diào)度的次數(shù)么？

第一個(gè)樣例里面倒是可以解釋：這證明工作線程的工作量對(duì)吞吐量產(chǎn)生了顯著的影響唄……而且工作線程工作量增加8倍，處理速度只降低了一倍，已經(jīng)可以了唄= =

其實(shí)你如果有興趣，根據(jù)這個(gè)就可以把上下文切換的代價(jià)計(jì)算出來了。其實(shí)并不大。

xxxxxxxp

回復(fù) 72# starwing83

沒有多出工作量啊，處理線程直接sleep，又不是分別執(zhí)行5ms或40ms的計(jì)算
   

folklore

看成
換個(gè)地方吹大牛
了

starwing83

回復(fù) 73# xxxxxxxp


    sleep以后被打斷會(huì)重新睡。根本不會(huì)提前醒的。

本質(zhì)上就是干了40ms的活兒，而且CPU占用率還非常低——時(shí)間都浪費(fèi)給時(shí)間片輪轉(zhuǎn)了，大家都沒干活。

xxxxxxxp

回復(fù) 52# windoze

按你這個(gè)分類，lightty的那種處理方式屬于proactor嘍？

linux_c_py_php

個(gè)人理解在操作系統(tǒng)自身不提供異步I/O接口的情況下, reactor和proactor相當(dāng)于網(wǎng)絡(luò)框架是否為用戶完成了網(wǎng)絡(luò)I/O操作, 即參考libevent的event和bufferevent, 前者只告知用戶發(fā)生了讀事件并傳給用戶的回調(diào), 后者則不僅監(jiān)聽了讀事件并將內(nèi)容讀回來之后回調(diào)交給用戶處理.

不知道自己理解是否有誤.

linux_c_py_php

lighttpd? 非網(wǎng)絡(luò)框架, 不需要考慮區(qū)分reactor / proactor,  從根上講是reactor, 實(shí)際上應(yīng)該就是個(gè)epoll, 對(duì)于linux來說, 這倆模式是沒有質(zhì)的區(qū)別的.

xxxxxxxp 發(fā)表于 2013-01-21 20:27
回復(fù) 52# windoze

按你這個(gè)分類，lightty的那種處理方式屬于proactor嘍？

xxxxxxxp

回復(fù) 75# starwing83

沒太懂，我現(xiàn)在的想法是處理時(shí)間短的場(chǎng)景吞吐量大，一小部分線程就可以勝任工作，以致cs較小
   

linux_c_py_php

做服務(wù)得綜合考慮以下, 給你個(gè)例子:

面對(duì)局域網(wǎng)和面對(duì)廣域網(wǎng)的服務(wù), 選網(wǎng)絡(luò)模型就要考慮的不一樣了, 因?yàn)榫W(wǎng)絡(luò)環(huán)境不同, 面對(duì)的用戶不同.

撇開攻擊不說, 最樸素的多線程模型1:1的服務(wù)模式, 各客戶端網(wǎng)絡(luò)延遲不同, 你的吞吐率就會(huì)直接受到用戶影響, 如果是采用epoll的1:n服務(wù)模式, 這種問題沒多大困擾.

但如果業(yè)務(wù)邏輯復(fù)雜耗時(shí), 那么多線程服務(wù)模式最簡(jiǎn)單實(shí)現(xiàn), 但單線程epoll+業(yè)務(wù)線程池會(huì)兼有兩種優(yōu)點(diǎn), 是更好的選擇.


不要研究什么模式了, 多寫幾個(gè)項(xiàng)目, 多吃點(diǎn)虧就見完所有模式了!

xxxxxxxp 發(fā)表于 2013-01-21 20:59
回復(fù) 75# starwing83

沒太懂，我現(xiàn)在的想法是處理時(shí)間短的場(chǎng)景吞吐量大，一小部分線程就可以勝任工作， ...