• <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 的專欄

            高性能服務器的多線程策略


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

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

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

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

            posted on 2008-03-06 00:09 eXile 閱讀(6977) 評論(9)  編輯 收藏 引用 所屬分類: 網絡開發(fā)

            評論

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

            頂 不錯
            內存申請針對線程內還是跨線程 決定是否采用加鎖策略,為了差異化這種處理,在內存池上進行進一步的封裝 不錯!  回復  更多評論   

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

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


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

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

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

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

            說錯了 呵呵 三次握手在accept前就完成了 從完成隊列里取而已  回復  更多評論   

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

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

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

            @cppexplore
            謝謝指正,不過cppexplore這么快就把測試模型搞出來,厲害,應該用的是什么庫吧,Apache?
              回復  更多評論   

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

            @eXile
            呵呵,還沒用庫。
            是我最近正在梳理網絡模型。這幾天正在寫各種模型的網絡程序并測試性能。
            等搞完這個再看各種庫是如何實現這些模型以及其性能如何。  回復  更多評論   

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

            領導者這個處理accept比較好。

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

            服務器雖然把網絡底層作為心臟,把架構作為骨架,但是還有一個很大的部分,就是血肉,也就是服務器的邏輯處理。

            很多人談高性能服務器的時候,忽略了邏輯處理,只是在談網絡底層的問題,這是非常錯誤的。

            網絡底層,只要符合我上面說的那個高性能服務器的標準,就可以在真正的服務器硬件上跑得很好了。

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

              回復  更多評論   

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

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

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

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

            不過,非本質復雜性 和 本質復雜性 都要處理好才好吧。無論性能還是復雜度。  回復  更多評論   

            導航

            <2013年10月>
            293012345
            6789101112
            13141516171819
            20212223242526
            272829303112
            3456789

            統(tǒng)計

            常用鏈接

            留言簿(18)

            隨筆分類

            隨筆檔案

            服務器編程

            搜索

            最新評論

            閱讀排行榜

            評論排行榜

            久久99精品久久久久婷婷| 伊人久久精品影院| 国内精品久久久久伊人av| 精品久久久噜噜噜久久久| 色综合久久久久网| 久久乐国产综合亚洲精品| 久久这里只有精品18| 国产免费久久精品99久久| 精品人妻伦九区久久AAA片69| 狠狠色噜噜狠狠狠狠狠色综合久久 | 一本久久综合亚洲鲁鲁五月天亚洲欧美一区二区 | 久久久久久久久波多野高潮| 国产精品久久久久…| 色综合久久88色综合天天 | 国产一久久香蕉国产线看观看| 区亚洲欧美一级久久精品亚洲精品成人网久久久久 | 三级三级久久三级久久| 国产成人精品白浆久久69| 午夜精品久久久久久影视777| avtt天堂网久久精品| 久久精品aⅴ无码中文字字幕不卡| 91麻豆精品国产91久久久久久| 漂亮人妻被黑人久久精品| 伊人久久国产免费观看视频| 国产精品激情综合久久| 久久久久久综合一区中文字幕| 久久精品无码午夜福利理论片 | 久久综合丝袜日本网| 久久久久亚洲AV片无码下载蜜桃 | 久久精品国产99久久丝袜| 精品久久久久久久| 久久久老熟女一区二区三区| 亚洲va久久久噜噜噜久久男同| 国产精品久久久久久五月尺| 久久久精品无码专区不卡| 国产香蕉97碰碰久久人人| 久久99精品久久久久久| 精品精品国产自在久久高清| 亚洲国产精品久久| 国产精品成人久久久久三级午夜电影 | 久久精品国产精品亚洲人人|