[換個地方發(fā)]請教大牛：異步io的優(yōu)點究竟在哪

windoze

xxxxxxxp 發(fā)表于 2013-01-21 18:21
兩個場景的上下文切換次數(shù)一致，性能當沒有大的差別

一個sleep 8ms，另一個sleep 40ms，你如何確定“上下文切換次數(shù)一致”呢？

liuspring6

贊同linux_c_py_php的看法，業(yè)務(wù)邏輯層的處理能力對整個結(jié)構(gòu)的影響往往遠高于網(wǎng)絡(luò)層的吞吐量，選什么模型取決于業(yè)務(wù)邏輯需求。有時候網(wǎng)絡(luò)層做的再牛B，碰到業(yè)務(wù)邏輯需要大量磁盤IO、數(shù)據(jù)庫訪問啥的，一樣卡得你蛋疼～～～

windoze

liuspring6 發(fā)表于 2013-01-21 22:17
贊同linux_c_py_php的看法，業(yè)務(wù)邏輯層的處理能力對整個結(jié)構(gòu)的影響往往遠高于網(wǎng)絡(luò)層的吞吐量，選什么模型取 ...

這個“往往”往往不成立啊…………
即便它成立，IO和并發(fā)模型也是很重要的東西，模型錯誤拖慢應(yīng)用的例子處處可見啊，例如著名的J2EE…………

liuspring6

回復 83# windoze

也許開發(fā)方向不同吧，個人接觸的方向大多有大量的數(shù)據(jù)庫操作，以及用戶與用戶，用戶與NPC之間的大規(guī)模交互，這部分邏輯消耗一般都遠大于傳輸層。
之前做過win32下線程池（用IOCP來管理）方式運行底層IO（包含文件和socket），但幾年的實踐證明，最忙碌的還是邏輯主線程（主邏輯十分復雜，基本不可能使用多線程并行模型），目前個人傾向于一個IO線程（IOCP/EPOLL/KQUEUE，利用超時分時間片） + 一個主邏輯線程 + N個可并行的業(yè)務(wù)邏輯線程

   

xxxxxxxp

回復 80# linux_c_py_php

我們的架構(gòu)中分前后端服務(wù)器，你說的和客戶交互時延不同的問題由前端服務(wù)器上的nginx等異步模型服務(wù)器來處理，他們不懼長連接（當然，攻擊問題得從其他層面來考慮）。
關(guān)注問題的焦點在后端服務(wù)器（目前都是HSHA的連接模型），后端服務(wù)器由于業(yè)務(wù)邏輯復雜，通常成百上千臺，且qps較低，想提升qps自然想到異步化，但異步化的代價就是對代碼結(jié)構(gòu)的破壞。這就涉及到一個權(quán)衡的問題，如果可以通過異步化少部分樞紐模塊來獲得極大的收益，這件事情就有做的意義，否則就是得不償失。這也是我現(xiàn)在的一個疑問。

xxxxxxxp

回復 77# linux_c_py_php

贊同你的理解，你的描述和@windoze的描述有出入，所以想確定一下，這些模型都見過，但今天對號入座了，討論討論，受益匪淺。沒有理解的事情是，proactor的優(yōu)勢在哪？似乎“reactor+非阻塞io”并沒有劣勢。
   

liuiang

不是搞這個方向的，不過昨晚認真的翻閱了所有的回帖，貌似學到了很多東西。mark一下，以備后用。

xxxxxxxp

回復 81# windoze


    本以為是這樣的，原以為在這兩個場景中造成cs的大頭在時間片和sleep，后來想想，不確切

ville_lee

個人覺得你的問題本身給出了答案。
同步和異步的優(yōu)劣主要取決于應(yīng)用場景而不是技術(shù)本身的問題。
完全的異步IO是你調(diào)用異步IO函數(shù)，然后立即返回接著執(zhí)行你的其他代碼邏輯，然后當你請求的數(shù)據(jù)準備好了，通過回調(diào)或者信號通知發(fā)起IO的進程。
所以說，如果數(shù)據(jù)準備的時間為t1，操作系統(tǒng)調(diào)度進程或者線程直到它能夠處理IO的時間為t2，那么，t1 > t2，異步的方式在執(zhí)行效率上會占優(yōu)勢，但是如果
t1 < t2，那么同步方式會占優(yōu)勢。
另外，采用異步IO方式的程序設(shè)計和代碼實現(xiàn)會比較困難，設(shè)計實現(xiàn)上對程序員要求更高，因為至少要求你的回調(diào)代碼是可重入的，并且對于服務(wù)器類型的程序而言，
就算是在好的設(shè)計，一個進程(單線程)的處理肯定是不夠的，因為數(shù)據(jù)量和吞吐率會非常高，所以還要采用多個線程，那么接著的問題就會是回調(diào)和信號都是以進程為單位發(fā)送的，
如何處理程序自身邏輯區(qū)分哪個線程請求了哪個數(shù)據(jù)，這可能就是一套大框架了。
我能想到的最后一點是CPU利用率的問題，完全是單個進程的程序?qū)τ诔�線程和多核的CPU的利用率不是很高。
同步多線程的程序幾乎沒有上述的問題，但是過多的線程也是一種系統(tǒng)資源消耗，所以也會有而外的消耗。

所以個人覺得，采用哪種框架，一要找出評估的標準，二要了解自己的需求和實際環(huán)境，三可能就真是實驗評估了。

windoze

本來Reactor+非阻塞io就沒什么問題，如果一定要說有問題也就是額外的排隊層會有一些同步開銷。
說到程序結(jié)構(gòu)，我覺得無論用什么模型，網(wǎng)絡(luò)服務(wù)程序從本質(zhì)上說就是一個狀態(tài)機，如果一開始就用這種結(jié)構(gòu)寫出來，改用任何模型都不是太麻煩的事。
最怕的就是一上來沒搞清楚狀態(tài)轉(zhuǎn)移關(guān)系，寫出一大坨充滿if/else/switch的程序。這種代碼除了用每連接一個線程的模型再沒法寫成別的樣子了