青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

eXile 的專欄

高性能服務(wù)器的多線程策略


(一)線程數(shù)量與線程池模型
  參見:high-performance server design. http://pl.atyp.us/content/tech/servers.html

  頻繁的上下文切換,會(huì)導(dǎo)致系統(tǒng)性能嚴(yán)重下降,而產(chǎn)生過多的切換大致有兩個(gè)原因:
  1)過多的線程數(shù)量。這會(huì)使系統(tǒng)性能呈指數(shù)級(jí)的下降。對(duì)于每連接一個(gè)線程的系統(tǒng)而言,這也是為什么性能會(huì)變差的原因。一個(gè)具有可伸縮性的系統(tǒng),它的唯一可行的選擇,就是限制運(yùn)行線程的數(shù)量。一般而言,這個(gè)值應(yīng)該小于或等于處理器的數(shù)目。(說明,在boost網(wǎng)絡(luò)庫(kù)asio提供的example中,有一個(gè)關(guān)于這種實(shí)現(xiàn)的很好的例子)
  2)所使用的線程池及事件模型。最簡(jiǎn)單的一種模型通常是這個(gè)樣子:一個(gè)偵聽線程異步地接收請(qǐng)求,并在隊(duì)列中進(jìn)行緩沖。另外一組工作者線程則負(fù)責(zé)處理這些請(qǐng)求。這是一個(gè)不錯(cuò)的模型,缺點(diǎn)就是每處理一個(gè)請(qǐng)求一般要經(jīng)過兩次線程切換(加上對(duì)請(qǐng)求的回復(fù))。為了避免這種缺點(diǎn),一個(gè)線程就必須具備偵聽者和工作者兩種角色,可以采用稱之謂“領(lǐng)導(dǎo)者/跟隨者”的模型。一個(gè)線程作為領(lǐng)導(dǎo)者,來進(jìn)行監(jiān)聽,當(dāng)收到請(qǐng)求時(shí),它選出一個(gè)跟隨者線程作為新的領(lǐng)導(dǎo)者進(jìn)行偵聽,自己則對(duì)請(qǐng)求進(jìn)行處理,結(jié)束后,到跟隨者隊(duì)列中進(jìn)行等待。

(二)多線程的內(nèi)存池優(yōu)化

  普通的內(nèi)存池一旦應(yīng)用到多線程中,都面臨著鎖競(jìng)爭(zhēng)的問題,在stlport所做的對(duì)于字符串性能的測(cè)試中,當(dāng)使用兩個(gè)線程時(shí),它所使用的內(nèi)存池node_allocator性能已經(jīng)出現(xiàn)明顯的下降。所以對(duì)于多線程而言,一個(gè)線程一個(gè)內(nèi)存池是一個(gè)很好的選擇。要實(shí)現(xiàn)這種設(shè)計(jì),面臨的第一個(gè)問題,是內(nèi)存塊的跨線程使用問題,即一個(gè)內(nèi)存塊,可能在A線程中申請(qǐng),但可能在B線程中釋放。
  在GCC的STL實(shí)現(xiàn)libstdc++中,有一個(gè)多線程內(nèi)存池的實(shí)現(xiàn)(mt_allocator)。它是node_allocator(現(xiàn)在叫pool_allocator) 的多線程版本。它還有一個(gè)優(yōu)點(diǎn)就是所有參數(shù)都是可配置的。
  它的設(shè)計(jì)思路如下:每個(gè)線程一個(gè)內(nèi)存池,同時(shí)還有一個(gè)全局的內(nèi)存池。每個(gè)線程可以訪問自己的內(nèi)存池,同時(shí)可在鎖保護(hù)下訪問全局內(nèi)存池。申請(qǐng)的每一個(gè)內(nèi)存塊中,都有一個(gè)線程ID,以標(biāo)明是從哪個(gè)線程中申請(qǐng)的。
  申請(qǐng)過程:首先向所在線程申請(qǐng),若本線程沒有空閑塊,則向全局內(nèi)存池申請(qǐng)。
  釋放過程:直接歸還到本線程的空閑鏈中。還有一個(gè)問題,為了防止線程內(nèi)存池之間的不均衡,或者某一個(gè)線程中的空閑鏈過長(zhǎng),可以設(shè)置一個(gè)水位標(biāo),當(dāng)超過這個(gè)水位標(biāo)時(shí),把釋放的內(nèi)存直接歸還到全局內(nèi)存池中。

posted on 2008-03-06 00:09 eXile 閱讀(6999) 評(píng)論(9)  編輯 收藏 引用 所屬分類: 網(wǎng)絡(luò)開發(fā)

評(píng)論

# re: 高性能服務(wù)器的多線程策略[未登錄] 2008-03-06 08:30 cppexplore

頂 不錯(cuò)
內(nèi)存申請(qǐng)針對(duì)線程內(nèi)還是跨線程 決定是否采用加鎖策略,為了差異化這種處理,在內(nèi)存池上進(jìn)行進(jìn)一步的封裝 不錯(cuò)!  回復(fù)  更多評(píng)論   

# re: 高性能服務(wù)器的多線程策略[未登錄] 2008-03-06 14:42 cppexplore

第一部分(2)的結(jié)論不太對(duì)。
主線程偵聽,預(yù)派生的線程處理業(yè)務(wù),這個(gè)稱為模型A吧.
leader/follow這里稱為B.
我服務(wù)器的4核的SMP,linux 2.6內(nèi)核,測(cè)試工具ab,小壓力的測(cè)試不說了,都能達(dá)到17000左右,測(cè)試項(xiàng)如下:
ab -c 4000 -n 40000 http://172.24.252.248:5000/
預(yù)派生線程數(shù)量都是4。
壓力測(cè)試的結(jié)果是:
業(yè)務(wù)邏輯簡(jiǎn)單的時(shí)候(僅僅是讀數(shù)據(jù),然后resonse200OK):
B模型多次測(cè)試平均的結(jié)果大約是每秒8500。
而A模型的性能和緩存隊(duì)列的大小有關(guān),當(dāng)緩存大小取500時(shí),和B模型性能相當(dāng)。取1000,測(cè)試的平均結(jié)果大約是每秒9500。取100則降低為6500左右


猜測(cè)原因:linux的pthread_mutex_t既然是非暫停點(diǎn)的實(shí)現(xiàn),那么它的性能一定很好,遠(yuǎn)好于條件鎖、信號(hào)燈等。pthread_cond_t則是暫停點(diǎn)的實(shí)現(xiàn),可能把線程推向睡眠。增大緩存大小,可以有效減少對(duì)pthread_cond_t的系統(tǒng)調(diào)用。

另根據(jù)對(duì)各種模型的測(cè)試,accept的處理速度非常非常的塊,簡(jiǎn)單的業(yè)務(wù)處理時(shí)間也要比accept的處理低一個(gè)數(shù)量級(jí)。因此單一線程處理accept,可以盡快建立三次握手,進(jìn)入緩存隊(duì)列等待。

因此猜測(cè) 如果業(yè)務(wù)為復(fù)雜邏輯(實(shí)際測(cè)試加了4個(gè)循環(huán)相加,一句打印的log)的話,模型B的性能將進(jìn)一步下降。增大業(yè)務(wù)處理復(fù)雜度后的結(jié)果果然如此,模型B的處理降低為6500左右,而模型A在1000的緩存下,每秒的處理能力還是9500左右。  回復(fù)  更多評(píng)論   

# re: 高性能服務(wù)器的多線程策略[未登錄] 2008-03-06 15:14 cppexplore

說錯(cuò)了 呵呵 三次握手在accept前就完成了 從完成隊(duì)列里取而已  回復(fù)  更多評(píng)論   

# re: 高性能服務(wù)器的多線程策略 2008-03-06 20:54 true

leader/followers模式不適合處理爆發(fā)  回復(fù)  更多評(píng)論   

# re: 高性能服務(wù)器的多線程策略 2008-03-06 22:36 eXile

@cppexplore
謝謝指正,不過cppexplore這么快就把測(cè)試模型搞出來,厲害,應(yīng)該用的是什么庫(kù)吧,Apache?
  回復(fù)  更多評(píng)論   

# re: 高性能服務(wù)器的多線程策略[未登錄] 2008-03-07 08:16 cppexplore

@eXile
呵呵,還沒用庫(kù)。
是我最近正在梳理網(wǎng)絡(luò)模型。這幾天正在寫各種模型的網(wǎng)絡(luò)程序并測(cè)試性能。
等搞完這個(gè)再看各種庫(kù)是如何實(shí)現(xiàn)這些模型以及其性能如何。  回復(fù)  更多評(píng)論   

# re: 高性能服務(wù)器的多線程策略[未登錄] 2008-03-08 10:55 小白

領(lǐng)導(dǎo)者這個(gè)處理accept比較好。

服務(wù)器只要不用弱智算法,以及處理好內(nèi)存和線程問題,就是高性能的服務(wù)器。

服務(wù)器雖然把網(wǎng)絡(luò)底層作為心臟,把架構(gòu)作為骨架,但是還有一個(gè)很大的部分,就是血肉,也就是服務(wù)器的邏輯處理。

很多人談高性能服務(wù)器的時(shí)候,忽略了邏輯處理,只是在談網(wǎng)絡(luò)底層的問題,這是非常錯(cuò)誤的。

網(wǎng)絡(luò)底層,只要符合我上面說的那個(gè)高性能服務(wù)器的標(biāo)準(zhǔn),就可以在真正的服務(wù)器硬件上跑得很好了。

接下來,我們需要面對(duì)的就是邏輯處理給我們的挑戰(zhàn)。無論在哪個(gè)行業(yè),都應(yīng)該仔細(xì)謹(jǐn)慎的去對(duì)邏輯處理進(jìn)行設(shè)計(jì)。

  回復(fù)  更多評(píng)論   

# re: 高性能服務(wù)器的多線程策略 2008-03-12 12:41 eXile

在現(xiàn)在gcc的mt_allocator實(shí)現(xiàn)中,有一個(gè)bug, 就是對(duì)一個(gè)計(jì)數(shù)器(_M_use)并沒有采用原子計(jì)數(shù),這個(gè)計(jì)數(shù)器主要用來控制空閑鏈的長(zhǎng)度,所以它并不會(huì)導(dǎo)致程序異常,但是可能會(huì)影響到程序性能,不過如果采用原子計(jì)數(shù),則有另一個(gè)性能上的擔(dān)憂。這個(gè)問題直到最新的gcc4.3中才得到解決。  回復(fù)  更多評(píng)論   

# re: 高性能服務(wù)器的多線程策略 2011-08-29 19:40 cingoli

小白 說得非常好啊,我做網(wǎng)游服務(wù)器開發(fā),著眼點(diǎn)也在這里。

不過,非本質(zhì)復(fù)雜性 和 本質(zhì)復(fù)雜性 都要處理好才好吧。無論性能還是復(fù)雜度。  回復(fù)  更多評(píng)論   

導(dǎo)航

<2025年9月>
31123456
78910111213
14151617181920
21222324252627
2829301234
567891011

統(tǒng)計(jì)

常用鏈接

留言簿(18)

隨筆分類

隨筆檔案

服務(wù)器編程

搜索

最新評(píng)論

閱讀排行榜

評(píng)論排行榜

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            麻豆国产精品一区二区三区| 亚洲欧美综合| 欧美日韩高清不卡| 一区二区三区.www| 夜夜爽99久久国产综合精品女不卡 | 精品成人在线| 麻豆精品视频在线| 欧美激情麻豆| 午夜影院日韩| 久久只有精品| 亚洲免费视频观看| 久久久精品2019中文字幕神马| 在线免费日韩片| 亚洲美女av网站| 国产欧美一区二区精品性色| 另类人畜视频在线| 欧美日韩黄色一区二区| 欧美一区精品| 欧美成人午夜| 欧美一区二区三区在| 久久精品99| 欧美激情视频网站| 久久久av毛片精品| 欧美日韩黄视频| 久久亚洲免费| 国产精品红桃| 亚洲第一精品影视| 国产乱人伦精品一区二区| 欧美二区乱c少妇| 国产精品蜜臀在线观看| 亚洲二区在线视频| 国产午夜久久久久| 日韩视频免费| 亚洲国产精品一区二区第一页| 中日韩午夜理伦电影免费| 在线观看亚洲视频| 亚洲欧美日韩国产综合在线| 99爱精品视频| 久久夜色精品国产欧美乱| 欧美亚洲日本一区| 欧美日韩亚洲系列| 亚洲高清视频一区| 在线观看国产一区二区| 亚洲欧美久久| 亚洲欧美区自拍先锋| 欧美精品一区二区久久婷婷| 久久综合中文| 韩国亚洲精品| 欧美在线视频播放| 久久精品人人做人人爽| 国产精品久久久一本精品| 亚洲伦理精品| 中国女人久久久| 欧美日韩一区二区在线| 亚洲精品小视频| 99精品国产在热久久下载| 美女视频黄免费的久久| 欧美成人综合一区| 亚洲欧洲三级| 欧美黄色免费| 日韩视频免费| 亚洲在线一区二区三区| 国产精品久久久久久久电影| 日韩一区二区精品葵司在线| 9人人澡人人爽人人精品| 欧美激情片在线观看| 亚洲欧洲一区二区三区在线观看| 99精品欧美| 欧美视频第二页| 亚洲在线观看免费| 久久久精品国产99久久精品芒果| 国产日本精品| 久久视频精品在线| 亚洲国产精品尤物yw在线观看| 亚洲激情婷婷| 欧美三级在线| 久久高清福利视频| 欧美激情久久久久久| 亚洲最新视频在线| 国产精品理论片| 久久国产日本精品| 亚洲国产精品成人| 亚洲欧美www| 国产综合久久| 欧美理论电影在线观看| 亚洲视频999| 久久嫩草精品久久久久| 亚洲精品久久嫩草网站秘色 | 一本大道av伊人久久综合| 亚洲欧美日韩国产中文在线| 国产亚洲高清视频| 欧美成人四级电影| 亚洲欧美成人| 亚洲激情网站| 欧美一区二区三区免费在线看| 激情欧美日韩| 欧美日韩直播| 久久久人人人| 亚洲午夜久久久| 欧美成人一区二区| 欧美一区二区高清| 亚洲精品欧美在线| 国产午夜久久| 欧美手机在线| 欧美jizz19性欧美| 欧美在线视频免费观看| 亚洲乱码国产乱码精品精可以看| 久久成人综合网| 亚洲精品一区二区三区不| 国产精品网站在线播放| 美国十次成人| 欧美一区二区在线观看| av成人免费| 欧美激情bt| 久久手机精品视频| 午夜激情久久久| 亚洲黄色片网站| 国内精品久久久久久 | 香蕉久久久久久久av网站| 欧美激情中文不卡| 久久久久九九九九| 性xx色xx综合久久久xx| 中文欧美在线视频| 亚洲欧洲一二三| 亚洲高清不卡一区| 激情视频亚洲| 国内精品久久久久伊人av| 国产精品日韩在线| 欧美小视频在线| 欧美激情综合色| 欧美+日本+国产+在线a∨观看| 欧美中文字幕第一页| 亚洲综合久久久久| 亚洲一区二区精品在线观看| 99视频精品在线| 亚洲精选在线| 一区二区三区免费看| 亚洲精品少妇30p| 一本色道久久88综合亚洲精品ⅰ| 亚洲经典三级| 日韩午夜黄色| 亚洲色诱最新| 亚洲午夜一区| 亚洲欧美日本伦理| 欧美影院午夜播放| 久久久久国产精品厨房| 久久精品国产v日韩v亚洲| 久久精品中文字幕一区| 久久在精品线影院精品国产| 久久一综合视频| 欧美久久久久久蜜桃| 欧美日韩国产精品一区| 欧美视频在线免费看| 国产伦精品一区二区三| 国产一区二区三区精品久久久| 一色屋精品亚洲香蕉网站| 在线精品亚洲一区二区| 亚洲三级性片| 亚洲在线视频网站| 久久久久久九九九九| 欧美成人久久| av成人免费在线观看| 亚洲专区一区| 久久香蕉国产线看观看av| 欧美精品色综合| 性做久久久久久久免费看| 久久久精品日韩| 亚洲激情影视| 亚洲精品一区二区三区婷婷月| 日韩图片一区| 久久国产精品久久国产精品| 免费在线观看一区二区| 亚洲精品美女91| 亚洲欧美日韩国产另类专区| 久久综合影音| 国产精品三级久久久久久电影| 有码中文亚洲精品| 亚洲欧美成人| 亚洲第一在线视频| 亚洲欧美日韩精品在线| 模特精品裸拍一区| 国产欧美日韩一区| 亚洲美女av黄| 久久综合色播五月| 亚洲性视频网址| 欧美激情按摩| 精品动漫3d一区二区三区免费| 日韩亚洲精品电影| 理论片一区二区在线| 宅男精品视频| 欧美精品一区二区精品网| 国内精品久久久久久影视8| 亚洲自拍啪啪| 最新日韩欧美| 美女精品国产| 狠狠爱综合网| 久久久999精品| 亚洲视频在线一区| 欧美精品一区在线| 亚洲精品久久久久久久久久久|