http://bbs.chinaunix.net/viewthread.php?tid=1214570&extra=&page=1
[保留] [算法] 超高性能網絡編程, Asynchronous network I/O
爲什麼是超高性能?
因爲常見資料太過普通, 沒有討論到核心問題.
本貼目的:
討論Linux下的高性能網絡編程.
熱烈歡迎參加討論, 或提供關鍵的技術參考資料. 最新的資料確實不好找.
項目背景:
流媒體交換服務器, 單臺服務器配置4個1Gbps 網口.
要求客戶連接超過1024, (單客戶約512kbps), 網絡滿負載運行, 實時性好.
參考產品:
華爲與3COM合作的 杭洲H3C公司的 MS8000媒體交換服務器, 最高併發量只達到1024路. 使用雙核CPU,4個 1Gbps網口.
MS8000媒體交換服務器
H3C還開發了面向電信高端的 媒體交換機. 基本框架應該是嵌入式, 在協議棧中實現流媒體交換. 在網絡性能上應該是馬馬虎虎.
H3C UMS9005 通用媒體交換機
網絡併發能力理論上應該達到物理極限.
所以發此貼, 還望國內的網絡高手不吝賜教! H3C MS8000的網絡性能也不見得就最優化.
重要資料:
[1]、 Dan Kegel - "The C10K problem"
http://www.kegel.com/c10k.html
主題: Web servers 同時處理10000個客戶端的技術問題,包括不同OS.
[2]、 Improving (network) I/O performance ...
http://www.xmailserver.org/linux-patches/nio-improve.html
epoll模型原理及性能測量結論.
[3]、 Drepper's New Network Interface (proposal for Linux 2.6+)
At OLS 2006, Ulrich Drepper proposed a new high-speed asynchronous networking API. See:
his paper, "The Need for Asynchronous, Zero-Copy Network I/O"
his slides :http://people.redhat.com/drepper/newni-slides.pdf
LWN article from July 22 : http://lwn.net/Articles/192410/
[4]、Benchmarking BSD and Linux
http://bulk.fefe.de/scalability/
在BSD 和Linux系統下，一系列網絡性能的測量對比。
註釋:
AIO: Asynchronous I/O;
以上的資料只到2006年底, 沒找到最新的.
epoll 只是事件通知模型. 沒有異步IO. 使用epoll 仍然需要用戶處理緩存.
Linux 下目前的AIO實現不支持socket, 可以支持文件AIO.
關於windows IOCP: 對用戶來講是異步模型. 但是, 其實現並不是真正的異步.
真正的AIO是由kernel完成, 不需要線程切換, 應當能實現Zero-Copy.
以下是在跟貼中提供的資料，整理一下方便使用：
[1]、High-Performance Server Architecture
http://pl.atyp.us/content/tech/servers.html
[2]、 高性能網絡編程，第 1 部分: 最大程度地利用您的網絡資源
http://www.ibm.com/developerwork ... perform1/index.html
高性能網絡編程，第 2 部分: 加快客戶機和服務器的處理速度
http://www.ibm.com/developerwork ... perform2/index.html
3樓 發表於 2008-7-17 11:09
我覺得性能的提升應該是多方面的。下面有一個資料：
http://www.ibm.com/developerwork ... perform2/index.html
4樓 發表於 2008-7-17 11:12
QUOTE:
原帖由 scutan 於 2008-7-17 11:09 發表
我覺得性能的提升應該是多方面的。下面有一個資料：
http://www.ibm.com/developerwork ... perform2/index.html
謝謝。
是有很多方而， 比如自己的緩存問題，mbuf /sk_buff。
但核心的還是通信模型的問題。如果是真正的異步模型就最理想。
9樓 發表於 2008-7-17 11:27
QUOTE:
原帖由 yunhappy 於 2008-7-17 11:24 發表
這麼看來 linux 2.6 的 epoll 效率很穩定嘛
是.
linux 2.6 幾乎在所有網絡操作的時候，效率都是 O(1)， 不會因數客戶數量上升而降低效率。
11樓 發表於 2008-7-17 12:42
其實在linux平臺下異步模型實際都是半同步和半異步這種模式.
epoll還是由單線程來操作的.
16樓 發表於 2008-7-17 15:10
LZ發的那些BSD和Linux的比較已經很老了
現在FreeBSD7.0出來了，多線程以及userland的jemalloc性能已經相當強了。
還有請問LZ，是想寫個高併發的呢？還是高相應的呢？
高併發的話，只拿着epoll和kqueue是不夠了，需要一個非常合理完善的框架。建議看看<POSA2>
其實所謂高性能是在整個框架的性能，而絕對不僅僅是兩個系統調用的事。
17樓 發表於 2008-7-17 16:03
QUOTE:
原帖由 zsniper 於 2008-7-17 15:10 發表
LZ發的那些BSD和Linux的比較已經很老了
現在FreeBSD7.0出來了，多線程以及userland的jemalloc性能已經相當強了。
還有請問LZ，是想寫個高併發的呢？還是高相應的呢？
高併發的話，只拿着epoll和kqueue ...
現在最重要的是網絡I/O的併發吞吐量問題. 古老的socket API 有性能限制, 像send()和recv()至少需要拷貝一次緩存. 所以纔有那麼多人討論AIO和Zero-Copy. 當然還有其它併發性能問題.
這個BSD和Linux的測試是2003年左右. 可以說明當時linux在網絡上的領先. 測試還證明OpenBSD根本不適合網絡服務器. 當然BSD會有改進.
18樓 發表於 2008-7-17 16:08
難道現在有什麼可以脫離write()和read()的方法嗎？？
至少要從mbuf拷貝到用戶空間。。如何zero-copy????
AIO只是一種事件通知方法，內核告訴應用程序有數據可讀或者有數據可寫，之後再read()和write()，難道你能zero-copy??
現在能做的只是在write()和read()的基礎上，搭建出高性能的框架~
19樓 發表於 2008-7-17 16:20
回覆 #18 zsniper 的帖子
這就是爲什麼這麼多人討論研究socket的併發問題和改進方案.
Ulrich Drepper 在論文裏提議的方案是直接訪問DMA, read()/receive()只需要返回一個DMA內存指針.
這些是研究性內容, 實現思路可以參考.
20樓 發表於 2008-7-17 16:53
其實，我覺得高併發的瓶頸在於你上層的實現，而不在於底層的read().
就我看來，花大精力放在上層實現，纔有意義。
還有就是，上層實現的時候，出現內存拷貝的情況很多，並不一定要不在乎系統底層的一點性能損失。
當然這是我的愚見，LZ的想法很好，希望能研究出成果來。。。
PS：支持鍵盤老農 ， 因爲kqueue性能真的很好，並且能支持普通文件(我不瞭解epoll) 。
21樓 發表於 2008-7-17 17:09
很是想知道 怎麼控制epoll的超時.
有連接進來後, 這個 連接什麼也不幹, 怎麼控制這個連接的超時呢?
22樓 發表於 2008-7-17 17:09
回覆 #21 yunhappy 的帖子
libevent可以解決超時問題，自己寫的話，效率沒有那麼高，
當然我也寫過一個用紅黑樹實現的超時，效率不高。。。。
我用的libevent-1.3的版本，他是用堆排序作的。可以參考一下。。
23樓 發表於 2008-7-17 17:39
我用epoll 測試過2W路的併發
找4臺設備, 每臺5000路, 每秒發一個數據包(5000併發), 每個數據包1400Bytes.
服務端CPU使用率40~50%
服務器配置: Intel(R) Pentium(R) 4 CPU 3.00GHz 雙核
25樓 發表於 2008-7-17 17:49
kqueue可以管網絡，文件，事件用的很爽，沒iocp那麼累還要考慮同步，iocp下對多個連接在做廣播時真的很難受。但倆者在功能和性能差不多，iocp也可以管文件讀取。epoll據傳說只管socket其他好像不行，沒有深入研究。一般情況下，程序運行的好壞跟寫程序的人有關係，就係統kqueue和iocp倆者的差別一般很難比較的出來。
對數據在傳遞時用拷貝還傳指針，指針會快很多，但一般我還會去拷貝，因爲傳指針在多線程下不確定性太大，安全第一。在我做的項目中3000-4000個客戶端佔用資源最厲害的是數據庫，其他現在的佔用資源很少。
26樓 發表於 2008-7-17 17:50
QUOTE:
原帖由 cookis 於 2008-7-17 17:39 發表
我用epoll 測試過2W路的併發
找4臺設備, 每臺5000路, 每秒發一個數據包(5000併發), 每個數據包1400Bytes.
服務端CPU使用率40~50%
服務器配置: Intel(R) Pentium(R) 4 CPU 3.00GHz 雙核
你做的反射還是廣播。
27樓 發表於 2008-7-17 17:51
回覆 #24 cookis 的帖子
高深 是指通過硬件控制麼?
29樓 發表於 2008-7-17 17:55
QUOTE:
原帖由 yunhappy 於 2008-7-17 17:51 發表
高深 是指通過硬件控制麼?
你的客戶端跟服務器之間沒有心跳機制嗎..我就是說的這個..
30樓 發表於 2008-7-17 17:56
QUOTE:
原帖由 鍵盤老農 於 2008-7-17 17:50 發表
你做的反射還是廣播。
服務器只收, 因爲當時主要是測試儀epoll的接收能力. TCP模式.
31樓 發表於 2008-7-17 20:28
回覆 #24 cookis 的帖子
服務器上不需要用心跳來控制超時，只需要記錄每個socket最後一次通信的時間戳，只需要用紅黑樹記錄這些點，設定的時間到了，就進行超時處理，在我的思路中，心跳只是超時處理函數的一種。
32樓 發表於 2008-7-17 22:02
回覆 #23 cookis 的帖子
10w併發也測試過,嘿嘿,客戶端不夠用,沒繼續加了,epoll支持樓主1024併發完全綽綽有餘.
就像樓上有位大哥說的,瓶頸肯定在應用層,保證好應用層代碼的性能就行,沒必要在i/o模型上鑽太多牛角尖.
33樓 發表於 2008-7-17 23:55
特定平臺上最優的IO模型幾乎是周知的，我覺得討論一下高性能服務器的進程/線程模型更實在。
34樓 發表於 2008-7-18 09:10
3.0GHz的CPU, 配上4個1Gbps網卡,理論上有4Gbps的網絡I/O. 瓶頸會在哪?
緩存拷貝的開銷的很大的. 線程切換代價也大. 多線程比較適合需要阻塞的場合.
通信模型是隻能依賴於OS, 剩下的是應用層.
我現在的思路,只有選擇epoll, 然後應用層協議棧參考TCP/IP, sk_buff/mmap.
據我查的資料, UNIX-like操作系統的網絡I/O還沒有實現內核級的異步. 如果把epoll封裝一下,看起來也會像kqueue或iocp.
35樓 發表於 2008-7-18 09:28
QUOTE:
原帖由 zsniper 於 2008-7-17 17:09 發表
libevent可以解決超時問題，自己寫的話，效率沒有那麼高，
當然我也寫過一個用紅黑樹實現的超時，效率不高。。。。
我用的libevent-1.3的版本，他是用堆排序作的。可以參考一下。。
謝謝各位!
用開源庫首先會增加函數堆棧. 像ACE雖然適跨合平臺,但也會有代價. libevent應該是個不錯的選擇.
36樓 發表於 2008-7-18 09:32
QUOTE:
原帖由 fm971 於 2008-7-18 09:10 發表
3.0GHz的CPU, 配上4個1Gbps網卡,理論上有4Gbps的網絡I/O. 瓶頸會在哪?
緩存拷貝的開銷的很大的. 線程切換代價也大. 多線程比較適合需要阻塞的場合.
通信模型是隻能依賴於OS, 剩下的是應用層.
我現在的思路 ...
多線程適合阻塞的場合？？？謬論！！！！
看過HAHS,LF這些框架嗎？再次建議你多看看POSA2
還需要說明的是，epoll本身就是以kqueue爲藍板開發的，所以在原理上kqueue和epoll一樣，但不等同於IOCP,
其實IOCP已經是一種框架了，而kqueue和epoll只是一種內核通知應用程序事件的API。
想要封裝epoll，其實就是做個框架，跟你本身做底層的想法又衝突了，請問LZ，你到底想做什麼？？？
37樓 發表於 2008-7-18 10:02
QUOTE:
原帖由 cookis 於 2008-7-17 17:41 發表
這個得通過你應用層的心跳來控制吧..
心跳不能處理那些惡意客戶端，連上來什麼事情也不做的，只回復你的心跳數據包~，佔着你的socket
所以說，心跳只是一個理論的方法，實際上需要一些其他技術。
38樓 發表於 2008-7-18 10:35
回覆 #31 zsniper 的帖子
就像QQ msn 都有心跳, 讓服務器知道它們還活着.. 而不是網絡中斷, 或主機已經斷電, 或程序崩潰, 這樣纔好管理這些client,
而不是一直持有它們所佔的資源.
我昨晚看了一下livevent 的 active timeout 機制, 它類似ACE的Heap_Timer的實現, 用堆排序, 將距離超時最近的放在頂端.
你爲什麼用紅黑樹呢, 紅黑樹只是查找快一些, 但timeout這種機制只是需要得到最大或最小的元素, 堆結構正適合,
我沒有細看. 我猜libevet只是檢測 是否在限定時間內收到第一個數據包. 是吧..
但如果有大量的無效的連接上來. 也發了一些程序不認識的數據, 那應用程序也是沒有辦法的.
我覺得這最好還是由應用層來控制, 爲每一次會話作一個狀態機, 當收到連接時, 生成一個會話對象, 由定時器來定時檢測每個狀態是否超時.
這些通信庫提供的功能越簡單越高效, 越穩定, 況且又不是所有人都有那樣的需求.
39樓 發表於 2008-7-18 10:38
QUOTE:
原帖由 zsniper 於 2008-7-18 10:02 發表
心跳不能處理那些惡意客戶端，連上來什麼事情也不做的，只回復你的心跳數據包~，佔着你的socket
所以說，心跳只是一個理論的方法，實際上需要一些其他技術。
你的心跳應該定製一個消息格式吧..惡意連接怎麼會知道這個格式呢.
40樓 發表於 2008-7-18 10:38
QUOTE:
原帖由 zsniper 於 2008-7-18 09:32 發表
多線程適合阻塞的場合？？？謬論！！！！
看過HAHS,LF這些框架嗎？再次建議你多看看POSA2
還需要說明的是，epoll本身就是以kqueue爲藍板開發的，所以在原理上kqueue和epoll一樣，但不等同於IOCP,
...
多謝指正. 我的目標當然是要實現最大的網絡I/O吞吐能力.
HAHS/LF/POSA2有它的適應場合. 但不是用在這種純粹的網絡I/O.
做以前的項目沒看過mbuf,HAHS, 但我的實現思路是一樣的.
有些人把事件通知模型封裝成類似的異步模型. 我也不瞭解kqueue原來是事件. 不過像IOCP的效率也已經不錯了.
41樓 發表於 2008-7-18 10:45
QUOTE:
原帖由 cookis 於 2008-7-18 10:35 發表
就像QQ msn 都有心跳, 讓服務器知道它們還活着.. 而不是網絡中斷, 或主機已經斷電, 或程序崩潰, 這樣纔好管理這些client,
而不是一直持有它們所佔的資源.
我昨晚看了一下livevent 的 active timeout 機制,
...........
我覺得這最好還是由應用層來控制, 爲每一次會話作一個狀態機, 當收到連接時, 生成一個會話對象, 由定時器來定時檢測每個狀態是否超時.
這些通信庫提供的功能越簡單越高效, 越穩定, 況且又不是所有人都有那樣的需求. ...
想法不錯. 在少量的線程裏面, 甚至單線程, 要處理上萬個socket, 你說這個定時器還能怎麼實現?
我的理解也只有排序和查找.
42樓 發表於 2008-7-18 10:51
回覆 #40 fm971 的帖子
能否講一下 sk_buff 在什麼環境下使用, 有什麼效果?
43樓 發表於 2008-7-18 10:52
QUOTE:
原帖由 cookis 於 2008-7-18 10:35 發表
就像QQ msn 都有心跳, 讓服務器知道它們還活着.. 而不是網絡中斷, 或主機已經斷電, 或程序崩潰, 這樣纔好管理這些client,
而不是一直持有它們所佔的資源.
我昨晚看了一下livevent 的 active timeout 機制, ...
紅黑樹難道不能知道最小值和最大值嗎？？
還有我也說了，這是我的效率很低的實現方法。
我想這應該比心跳來的更靈活吧~
我現在的實現方法，就是基於libevent的超時機制，超時 後再調用自己設定的函數，發出確認數據包，沒有收到時，就close();
44樓 發表於 2008-7-18 10:56
回覆 #41 fm971 的帖子
如果要單線程的話. 定時器的驅動就得是epoll 或select了.
只排序就行了. 不用查找. 我們只需要得到與當前時間相差最大的定時器對象就可以了.
45樓 發表於 2008-7-18 11:00
回覆 #43 zsniper 的帖子
我沒有說紅黑樹得不到最大值和最小值. 我只是想說堆結構更適合這種只需要最大值和最小值的需求
其實仔細想想. 如果爲每個連接做一個超時機制. 還不如單獨做一個定時器來定時檢查所有的連接是否超時.
這樣喚醒epoll 或kqueue的機會要少得多. 也就是epoll 或 kqeueu的處理非socket事件的壓力要少得多.
46樓 發表於 2008-7-18 11:04
回覆 #45 cookis 的帖子
我覺得自己寫效率不是很高，因爲技術還達不到，
所以我就建議用libevent.
還有在我的程序裏面，只要接受到封包格式錯誤的數據包，我就認爲這是非法數據包，直接close()，所以不用擔心客戶端不斷髮送惡意數據包的情況。
47樓 發表於 2008-7-18 11:07
回覆 #46 zsniper 的帖子
我覺得沒什麼神祕的..只要你用對了算法. 效率跟他一樣.
我想請教一個問題. 我在libevent中沒有看到互斥. 那麼它是怎麼運轉event_loop 的. 如果我有新的socket要註冊進去怎麼辦
而且我整個服務也不可能只有一個線程啊.
48樓 發表於 2008-7-18 11:26
回覆 #47 cookis 的帖子
event_loop就是單線程的阿~
localsocket就是等待accept事件，新的socket進來後，再通過回調函數設置讀寫事件，加入eventbase
49樓 發表於 2008-7-18 11:33
回覆 #48 zsniper 的帖子
OK
event_loop run with thread1
業務邏輯肯定運行在另外一個線程thread2. 如果thread2 想註冊或先移除一個socket.
不能直接操作event_list吧.
50樓 發表於 2008-7-18 11:41
回覆 #49 cookis 的帖子
業務邏輯在上層完成，完成後讓IO_MAIN_THREAD處理註冊或先移除一個socket
之間用隊列聯繫起來，
這就是所謂的HAHS模式。
51樓 發表於 2008-7-18 12:19
回覆 #50 zsniper 的帖子
no..no.
我還是無法理解. 在沒有互斥的情況下. 其他線程怎麼通知所謂的 IO_MAIN_THREAD 註冊或移除 socket
53樓 發表於 2008-7-18 15:12
linux最新的內核有實現真正的AIO嗎？
54樓 發表於 2008-7-18 15:59
QUOTE:
原帖由 cookis 於 2008-7-18 10:51 發表
能否講一下 sk_buff 在什麼環境下使用, 有什麼效果?
Linux 的 TCP/IP協議棧是用sk_buff, 主要滿足協議棧對緩存的要求, 比如各層之間的透明.
另一種被討論的方法, 大概叫"分散/聚合緩存", 通過一次內存操作可以處理不同位置的內存分片. 會有優勢的地方.
55樓 發表於 2008-7-18 16:08
QUOTE:
原帖由 cookis 於 2008-7-18 11:33 發表
OK
event_loop run with thread1
業務邏輯肯定運行在另外一個線程thread2. 如果thread2 想註冊或先移除一個socket.
不能直接操作event_list吧.
一般來說應該有鎖操作. libevent怎麼實現我也不知道.
做自己的協議棧一般不會用開源庫, 比如說在嵌入式機的 IP/TCP/ 上再實現一層. 目前我也不用libevent.
56樓 發表於 2008-7-18 16:17
中小量鏈接用select
大量用epoll等（操作系統依賴）
58樓 發表於 2008-7-18 17:12
呵呵，我現在做的東西跟樓主做的幾乎一樣，也是交換數據的，說說自己的一些看法。
(1) I/O 模型的選擇，
epoll就一定好嗎? epoll最有用的就是ET模式，適合於那種有大量連接，但是有數據連接有限的情況，
如果你有10000個連接，但是很不幸，這10000個連接全部都有數據，你還是得遍歷一把進行處理，( 這裏對ET模式下怎麼處理數據就不討論了)。
這個和select, poll有什麼區別。
epoll還有比select, poll先進得地方， 就在於將fd得列表維護在內核中， 而select, poll是調用一次，傳遞一次， 這點epoll領先是沒得說得。
但是如果我是每個線程處理100個連接， 分10個線程來處理1000個連接， 那麼上面得優點幾乎可以不考慮。
模型得選擇要符合自己得程序架構，不見得最先進的東西就適合你
(2) 使用非堵塞
做爲網絡服務器， 堵塞I/O一般情況下不予考慮
(3) 減少I/O操作和無謂的系統調用
比如利用writev一次性寫入多個數據， 減少write調用的次數.
(4) tcp是雙工的
這點不要忽略掉， 數據轉發程序就在於數據的轉發速度， 這裏我採用讀和寫分開線程的處理方式
(5) 進程還是線程
這個無關緊要，一個粒度和數據訪問， 穩定性的問題。減少之間的相互影響，儘量沒有關聯， 比如減少對相關互斥數據的訪問等等。
(6) 儘量在設計上做到不需要同步
比如使用環形?
61樓 發表於 2008-7-18 17:26
QUOTE:
原帖由 unixpm 於 2008-7-18 17:12 發表
這10000個連接全部都有數據，你還是得遍歷一把進行處理，
爲什麼要遍歷一把.. epoll已經將活動的句柄全部返回了..剩下的是你自己定位的算法問題了..是遍歷還是用fd索引
65樓 發表於 2008-7-20 16:01
實際的說，基於Generic OS（Linux/*nix/Windows）的Network I/O都存在理論速度上限的瓶頸，因爲OS自身的開銷（任務切換，虛擬內存轉換等），總線的時延，較低的總線帶寬等等都會大幅降低I/O性能，而這是軟件本身無法解決的硬傷。
如果你的方案確實需要處理非常大的流量，比如LZ前面提到的H3C的產品，建議還是採用硬件方案（NP、FPGA etc)
個人認爲，純軟件的方式，要想讓實際處理能力接近理論值，是非常困難的，即使達到了，過低的收益比也會大幅度降低其價值。
LZ提及的 "H3C UMS9005"從其官方資料推測來看，應該是基於H3C or HW某款較高端的數通產品開發而成的，通常這樣的產品都是基於NP架構的（網絡流量由快速的數據面處理，各個線路板之間採用高速交換網進行數據交換），和你提到的AIO沒有啥關係，放在一起比沒有任何意義。
另外基於Linux/*nix的純軟件方案，在高可靠性(HA)上有其致命的硬傷，不可能用在關鍵業務上。
66樓 發表於 2008-7-21 09:26
QUOTE:
原帖由 unixpm 於 2008-7-18 17:13 發表
呵呵，我現在做的東西跟樓主做的幾乎一樣，也是交換數據的，說說自己的一些看法。
(1) I/O 模型的選擇，
epoll就一定好嗎? epoll最有用的就是ET模式，適合於那種有大量連接，但是有數據連接有限的情況， ...
不錯. 有兩個點很值得關注, contect-switches, IP 分片.
67樓 發表於 2008-7-21 09:53
QUOTE:
原帖由 Kendiv 於 2008-7-20 16:01 發表
實際的說，基於Generic OS（Linux/*nix/Windows）的Network I/O都存在理論速度上限的瓶頸，因爲OS自身的開銷（任務切換，虛擬內存轉換等），總線的時延，較低的總線帶寬等等都會大幅降低I/O性能，而這是軟件本身 ...
多謝指點. 研究網絡的也包括國外一些內核相關的專家。假設能實現 AIO/Zero-Copy當然就很理想。
因爲純軟件方案開發成本低、硬件成本低, 可以適合很多場合.
UMS9005雖說是硬件方案，有它的可靠性等特性。但只能帶4塊業務板，每塊板最大8Gbps。如果軟件方案也接近8Gbps，就有得比了。
軟件方案相對來說是有它的可靠性等劣勢。但是像OS裏的TCP/IP協議棧也屬於軟件，可靠性是能經受考驗的。
68樓 發表於 2008-7-21 10:00
QUOTE:
原帖由 Kendiv 於 2008-7-20 16:01 發表
實際的說，基於Generic OS（Linux/*nix/Windows）的Network I/O都存在理論速度上限的瓶頸，因爲OS自身的開銷（任務切換，虛擬內存轉換等），總線的時延，較低的總線帶寬等等都會大幅降低I/O性能，而這是軟件本身 ...
確實.. 軟件費半天勁優化, 有時還不如多花點兒錢升級一下設備.
69樓 發表於 2008-7-21 10:27
QUOTE:
原帖由 fm971 於 2008-7-21 09:53 發表
... 每塊板最大8Gbps。如果軟件方案也接近8Gbps，就有得比了。
軟件方案相對來說是有它的可靠性等劣勢。但是像OS裏的TCP/IP協議棧也屬於軟件，可靠性是能經受考驗的。
嗯，軟件達到8Gbps?? 你用8塊1G的網卡？ 還是10塊？ 使用普通的小型機嗎？（1U/2U）？？？ 那種分時複用的總線機制能達到8*1G=8Gbit?
還有，我所指的可靠性並不是指協議棧是否可靠，比如當設備在線時，如果某個網口突然down掉，你如何處理？系統關鍵組件死掉後，是否能及時自動啓動/恢復?
還有就是是否能保證業務中斷時間始終位於一個下限範圍裏？等等。
70樓 發表於 2008-7-21 11:07
QUOTE:
原帖由 Kendiv 於 2008-7-21 10:27 發表
嗯，軟件達到8Gbps?? 你用8塊1G的網卡？ 還是10塊？ 使用普通的小型機嗎？（1U/2U）？？？ 那種分時複用的總線機制能達到8*1G=8Gbit?
還有，我所指的可靠性並不是指協議棧是否可靠，比如當設備在線時，如 ...
你說的沒錯. 硬件版是有很多優勢. 但是要用NP/ASIC架構我不知道要多少成本!
他們的8Gbps也只是理論值. 如果用PC架構的高端服務器, IO能力還是不同的.
71樓 發表於 2008-7-21 11:51
嗯，性能和成本本來就是相互矛盾的東西，呵呵。
72樓 發表於 2008-7-21 14:47
這種硬件系統是怎麼解決速度問題的。。
76樓 發表於 2008-7-31 17:26
可以肯定的說這不叫超高性能。單機50w~100w的連接同時在線，還勉強能稱.按樓主描述的， 視頻這樣的東西，用select監視描述符，足夠了。
同樣的系統調用，和邏輯結構，不同的程序員實現起來差別n大。。。
77樓 發表於 2008-7-31 18:46
QUOTE:
原帖由 wyezl 於 2008-7-31 17:26 發表
可以肯定的說這不叫超高性能。單機50w~100w的連接同時在線，還勉強能稱.按樓主描述的， 視頻這樣的東西，用select監視描述符，足夠了。
同樣的系統調用，和邏輯結構，不同的程序員實現起來差別n大。。。
願聞其詳!
80樓 發表於 2008-8-7 16:51
sports.sinajs.cn 單機每秒可以處理15w+ http請求,支撐50w+ connections同時在線.在2cpu 4核機器上測試。
hq.sinajs.cn 每天上百億http請求。
系統資源都比較空閒，負載比較低。。。
sports.sinajs.cn單機每秒可以處理15w+ http請求,支撐50w+ connections同時在線.在2cpu 4核機器上測試。hq.sinajs.cn 每天上百億http請求。系統資源都比較空閒，負載比較低。。。
81樓 發表於 2008-8-9 02:26
回覆 #80 wyezl 的帖子
你這個是網站是吧，跟H3C的東西完全是兩碼事，別人那是視頻。
83樓 發表於 2008-8-9 22:24
回覆 #81 idsel 的帖子
看標題 超高性能網絡編程, Asynchronous network I/O
底層技術換湯不換藥。
84樓 發表於 2008-8-10 01:02
回覆 #83 wyezl 的帖子
你的意思是一個服務器支持幾萬到幾十萬路視頻？？？？？呵呵~~
85樓 發表於 2008-8-10 10:17
似乎還沒有很好的AIO實現吧
glibc記得使用線程模擬的
86樓 發表於 2008-8-10 20:59
QUOTE:
原帖由 idsel 於 2008-8-10 01:02 發表
你的意思是一個服務器支持幾萬到幾十萬路視頻？？？？？呵呵~~
哥們，這話我可沒說。
視頻種東西，佔用大量帶寬，可能10k用戶不到，1G帶寬就跑滿了。
10k以下的服務，算不上 “高性能網絡編程”，更不要說“超高了”。
用epoll就相當於殺雞用牛刀。
要根據服務的特點去決定你要用什麼網絡i/o模型。
視頻服務的瓶頸並不在監視大量的閒散connections上。
個人覺得，select 足夠了。
就更下象棋一樣，卒子用好了，一樣能將軍。
88樓 發表於 2008-8-28 08:56
QUOTE:
原帖由 wyezl 於 2008-8-7 16:51 發表
sports.sinajs.cn 單機每秒可以處理15w+ http請求,支撐50w+ connections同時在線.在2cpu 4核機器上測試。
hq.sinajs.cn 每天上百億http請求。
系統資源都比較空閒，負載比較低。。。
"單機每秒可以處理15w+ http請求"，取決於每個請求要做多少事情，如果每個請求的工作量都很小，那麼只要用合適的方式做好accept就可以了。每秒要做14w次socket accept，這種應用比較罕見。
“支撐50w+ connections同時在線”，這個在線是什麼意思，http有在線的嗎？邏輯上的login，有500w也沒關係吧？
“每天上百億http請求”，按照24小時算是平均每秒11w，峯值估計是平均值的3-5倍，那麼就是每秒30w到50w。數字比上面的例子大一點，不過關鍵點類似。
我猜，sports.sinajs.cn和hq.sinajs.cn應該都是一個類似路由的東西吧，應該是負責分發請求的。一臺機器來搞定所有事情，是不符合可擴展性的要求的。
89樓 發表於 2008-8-28 09:06
http://www.xmailserver.org/linux-patches/nio-improve.html
測試說明dual PIII 1GHz, 256 Mb RAM的機器，每秒可以處理約27500個128字節的http請求。
“2cpu 4核機器” 比 “dual PIII 1GHz”的性能高五倍，也算一個reasonable的數值吧。
90樓 發表於 2008-9-9 17:52
QUOTE:
原帖由 wwwsq 於 2008-8-28 08:56 發表
"單機每秒可以處理15w+ http請求"，取決於每個請求要做多少事情，如果每個請求的工作量都很小，那麼只要用合適的方式做好accept就可以了。每秒要做14w次socket accept，這種應用比較罕見。
“支撐50w+ ...
不是類似路由的東西，而是一個類似apache的東西。
當然，如果我願意，我可以稍微修改就能成爲高效的類似路由的東西或者一個高效的代理服務器。
低層技術都不變，作爲什麼服務，只是一種表現。
50w+ connections ， 就是說，有50w人都連接了這個服務器，而且每幾秒可能都有一個請求，建立的連接會一直保持着。有走的有來的，50w是活着的連接。
我們擴展性非常好，可以線性擴展。
你的猜測都只有部分正確。
肯定是沒有自己動手寫過這種東西。
91樓 發表於 2008-9-9 18:00
QUOTE:
原帖由 wwwsq 於 2008-8-28 09:06 發表
http://www.xmailserver.org/linux-patches/nio-improve.html
測試說明dual PIII 1GHz, 256 Mb RAM的機器，每秒可以處理約27500個128字節的http請求。
“2cpu 4核機器” 比 “dual PIII 1GHz”的性能高五 ...
不reasonable，我怎麼能實現呢。
不過，這個效率我還能提高不少，以前取數據耽誤不少時間，我要是願意可以把取數據的效率提高50倍。
等有人超過我了，我再做改進，現在懶得動。
92樓 發表於 2008-9-9 18:07
QQ服務器是怎樣的架構？
93樓 發表於 2008-9-9 19:17
QUOTE:
原帖由 wyezl 於 2008-9-9 17:52 發表
不是類似路由的東西，而是一個類似apache的東西。
當然，如果我願意，我可以稍微修改就能成爲高效的類似路由的東西或者一個高效的代理服務器。
低層技術都不變，作爲什麼服務，只是一種表現。
50w ...
如果每秒15w的http請求是通過長連接實現的，那就比較好理解，我見過一個服務器每秒鐘處理100w+的request，每個request大概十幾個字節。
據我所知accept的時候socket底層是要做很多分配buffer之類的體力活的，對於長連接，那麼請求只是數據流。
94樓 發表於 2008-9-9 19:19
QUOTE:
原帖由 wyezl 於 2008-9-9 18:00 發表
不reasonable，我怎麼能實現呢。
不過，這個效率我還能提高不少，以前取數據耽誤不少時間，我要是願意可以把取數據的效率提高50倍。
等有人超過我了，我再做改進，現在懶得動。
取數據的效率提高50倍，是把accept和recv合併爲一次內核操作嗎？或者是把自己的程序變成一個kernel module ？
95樓 發表於 2008-9-9 21:06
QUOTE:
原帖由 Kendiv 於 2008-7-20 16:01 發表
實際的說，基於Generic OS（Linux/*nix/Windows）的Network I/O都存在理論速度上限的瓶頸，因爲OS自身的開銷（任務切換，虛擬內存轉換等），總線的時延，較低的總線帶寬等等都會大幅降低I/O性能，而這是軟件本身 ...
採用NP方案一般適合路由器這種IP層的處理。如果用NP來實現基於TCP的應用層（如web), 應該怎麼架構呢？
96樓 發表於 2008-9-10 15:06
QUOTE:
原帖由 cookis 於 2008-7-18 10:35 發表
你爲什麼用紅黑樹呢, 紅黑樹只是查找快一些, 但timeout這種機制只是需要得到最大或最小的元素, 堆結構正適合
使用複雜數據結構的話都有維護的成本, 多線程情況下, 還需要加鎖處理
不如設定一個超時輪詢線程, 將所有現有的連接按時間戳排序, 然後依次排除
97樓 發表於 2008-9-10 15:19
QUOTE:
原帖由 wwwsq 於 2008-9-9 19:17 發表
我見過一個服務器每秒鐘處理100w+的request，每個request大概十幾個字節。
...
哥們這服務器什麼配置。網絡I/O能達到這個數？
98樓 發表於 2008-9-11 17:55
QUOTE:
原帖由 wyezl 於 2008-9-10 15:19 發表
哥們這服務器什麼配置。網絡I/O能達到這個數？
千兆網。
100w乘以15字節=15M字節。
99樓 發表於 2008-9-12 11:51
QUOTE:
原帖由 wyezl 於 2008-8-7 16:51 發表
sports.sinajs.cn 單機每秒可以處理15w+ http請求,支撐50w+ connections同時在線.在2cpu 4核機器上測試。
hq.sinajs.cn 每天上百億http請求。
系統資源都比較空閒，負載比較低。。。
剛剛看到有人說, 受限於 non-paged Kernel memory, 4G 內存的 windows 系統, 同一時間 15w 左右的 socket 是極限
不知道 linux/unix 的情況怎麼樣?
100樓 發表於 2008-9-12 12:35
QUOTE:
原帖由 wwwsq 於 2008-9-11 17:55 發表
千兆網。
100w乘以15字節=15M字節。
只知其一不知其二。
先不算要維持一個http只連接，http頭至少要70多字節，只發個hello world加起來也要80字節。
就算只發15個字節，千兆網又能如何，普通網卡一秒也就只能發20w個包。
按你的說法，我如果每個包一個字節，那麼一秒發500w個包也很輕鬆了。。。
就算我用最好的網卡，按我說的這樣的普通服務器，每秒50w http處理量，絕對世上罕見,不過對我來說不是很難實現。
101樓 發表於 2008-9-12 14:59
QUOTE:
原帖由 wyezl 於 2008-9-12 12:35 發表
只知其一不知其二。
先不算要維持一個http只連接，http頭至少要70多字節，只發個hello world加起來也要80字節。
就算只發15個字節，千兆網又能如何，普通網卡一秒也就只能發20w個包。
按你的說法 ...
並不是每個request都是一個單獨的tcp packet，在一個數據包裏面可以有很多個request。
102樓 發表於 2008-9-13 12:04
QUOTE:
原帖由 fm971 於 2008-7-17 11:03 發表
爲什麼是超高性能?
因爲常見資料太過普通, 沒有討論到核心問題.
本貼目的:
討論Linux下的高性能網絡編程.
熱烈歡迎參加討論, 或提供關鍵的技術參考資料. 最新的資料確實不好找.
項目背景:
流媒 ...
我謹慎懷疑這個AIO的效率問題, 估計只是用了一個獨立線程循環發送罷了...
104樓 發表於 2008-10-6 11:08
QUOTE:
原帖由 fm971 於 2008-7-21 11:07 發表
你說的沒錯. 硬件版是有很多優勢. 但是要用NP/ASIC架構我不知道要多少成本!
他們的8Gbps也只是理論值. 如果用PC架構的高端服務器, IO能力還是不同的.
真正的服務器和PC架構的還是不同，性能要好多