• <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>

            eXile 的專欄

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


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

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

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

              普通的內(nèi)存池一旦應(yīng)用到多線程中,都面臨著鎖競(jìng)爭(zhēng)的問(wèn)題,在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è)問(wèn)題,是內(nèi)存塊的跨線程使用問(wèn)題,即一個(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è)線程可以訪問(wèn)自己的內(nèi)存池,同時(shí)可在鎖保護(hù)下訪問(wèn)全局內(nèi)存池。申請(qǐng)的每一個(gè)內(nèi)存塊中,都有一個(gè)線程ID,以標(biāo)明是從哪個(gè)線程中申請(qǐng)的。
              申請(qǐng)過(guò)程:首先向所在線程申請(qǐng),若本線程沒(méi)有空閑塊,則向全局內(nèi)存池申請(qǐng)。
              釋放過(guò)程:直接歸還到本線程的空閑鏈中。還有一個(gè)問(wèn)題,為了防止線程內(nèi)存池之間的不均衡,或者某一個(gè)線程中的空閑鏈過(guò)長(zhǎng),可以設(shè)置一個(gè)水位標(biāo),當(dāng)超過(guò)這個(gè)水位標(biāo)時(shí),把釋放的內(nèi)存直接歸還到全局內(nèi)存池中。

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

            評(píng)論

            # re: 高性能服務(wù)器的多線程策略[未登錄](méi) 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ù)器的多線程策略[未登錄](méi) 2008-03-06 14:42 cppexplore

            第一部分(2)的結(jié)論不太對(duì)。
            主線程偵聽(tīng),預(yù)派生的線程處理業(yè)務(wù),這個(gè)稱為模型A吧.
            leader/follow這里稱為B.
            我服務(wù)器的4核的SMP,linux 2.6內(nèi)核,測(cè)試工具ab,小壓力的測(cè)試不說(shuō)了,都能達(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ù)器的多線程策略[未登錄](méi) 2008-03-06 15:14 cppexplore

            說(shuō)錯(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
            謝謝指正,不過(guò)cppexplore這么快就把測(cè)試模型搞出來(lái),厲害,應(yīng)該用的是什么庫(kù)吧,Apache?
              回復(fù)  更多評(píng)論   

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

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

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

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

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

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

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

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

            接下來(lái),我們需要面對(duì)的就是邏輯處理給我們的挑戰(zhàn)。無(wú)論在哪個(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)并沒(méi)有采用原子計(jì)數(shù),這個(gè)計(jì)數(shù)器主要用來(lái)控制空閑鏈的長(zhǎng)度,所以它并不會(huì)導(dǎo)致程序異常,但是可能會(huì)影響到程序性能,不過(guò)如果采用原子計(jì)數(shù),則有另一個(gè)性能上的擔(dān)憂。這個(gè)問(wèn)題直到最新的gcc4.3中才得到解決。  回復(fù)  更多評(píng)論   

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

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

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

            導(dǎo)航

            <2008年3月>
            2425262728291
            2345678
            9101112131415
            16171819202122
            23242526272829
            303112345

            統(tǒng)計(jì)

            常用鏈接

            留言簿(18)

            隨筆分類

            隨筆檔案

            服務(wù)器編程

            搜索

            最新評(píng)論

            閱讀排行榜

            評(píng)論排行榜

            亚洲国产精品成人久久蜜臀| 潮喷大喷水系列无码久久精品| 国产亚洲精久久久久久无码AV| 99国产欧美精品久久久蜜芽| 国产叼嘿久久精品久久| 国产精品久久久天天影视香蕉| 久久精品中文字幕大胸| 亚洲AV日韩AV天堂久久| 品成人欧美大片久久国产欧美... 品成人欧美大片久久国产欧美 | 国产69精品久久久久777| 国产精品熟女福利久久AV| 久久久国产打桩机| 精品久久久久久国产三级| 人妻丰满AV无码久久不卡| 色综合久久综精品| 久久久一本精品99久久精品66| 久久久久久久久久久免费精品| 欧美一区二区三区久久综| 性做久久久久久久久| 久久最新精品国产| 九九精品99久久久香蕉| 波多野结衣AV无码久久一区| 久久人人爽人人爽人人片AV东京热| 亚洲va国产va天堂va久久| 国产精品久久久久久久久久影院 | 亚洲天堂久久精品| 国产精品久久午夜夜伦鲁鲁| 偷偷做久久久久网站| 亚洲精品99久久久久中文字幕| 99久久99久久精品国产片果冻| 国产精品禁18久久久夂久| 久久人人爽人人爽人人AV东京热| 久久久久人妻一区二区三区| 国产精品乱码久久久久久软件| 久久亚洲电影| 午夜视频久久久久一区| 亚洲欧洲精品成人久久奇米网| 久久这里只有精品首页| 欧美国产成人久久精品| 久久精品成人一区二区三区| 久久免费大片|