高效能伺服器架構 第一篇

來源:互聯網
上載者:User

 

轉自:http://www.doserv.com/article/2012/0831/5299117.shtml

 

本文不會涉及到多任務應用程式,在單個程式裡同時處理多個任務現在已經很常見。比如你的瀏覽器可能就在做一些平行處理,但是這類並行程式設計沒有多大挑戰性. 真正的挑戰出現在伺服器的架構設計對效能產生制約時,如何通過改善架構來提升系統效能. 對於在擁有上G記憶體和G赫茲CPU上啟動並執行瀏覽器來說,通過DSL進行多個並發下載任務不會有如此的挑戰性. 這裡,應用的焦點不在於通過吸管小口吮吸,而是如何通過水龍頭大口暢飲,這裡麻煩是如何解決在硬體效能的制約.(作者的意思應該是怎麼通過網路硬體的改善來增大流量)

一些人可能會對我的某些觀點和建議發出置疑,或者自認為有更好的方法, 這是無法避免的. 在本文中我不想扮演上帝的角色;這裡所談論的是我自己的一些經驗,這些經驗對我來說, 不僅在提高伺服器效能上有效,而且在降低調試困難度和增加系統的可擴充性上也有作用. 但是對某些人的系統可能會有所不同. 如果有其它更適合於你的方法,那實在是很不錯. 但是值得注意的是,對本文中所提出的每一條建議的其它一些可替代方案,我經過實驗得出的結論都是悲觀的. 你自己的小聰明在這些實驗中或許有更好的表現,但是如果因此慫恿我在這裡建議讀者這麼做,可能會引起無辜讀者的反感.
你並不想惹怒讀者,對吧?

本文的其餘部分將主要說明影響伺服器效能的四大殺手:

1) 資料拷貝Data Copies -- 技巧什麼的

2) 環境切換Context Switches -- 理性建立線程

3) 記憶體配置Memory allocation -- 記憶體池

4) 鎖競爭Lock contention -- 沒有好的辦法, 和具體的業務特點, 軟體的設計結構有密切的聯絡

在文章結尾部分還會提出其它一些比較重要的因素,但是上面的四點是主要因素. 如果伺服器在處理大部分請求時能夠做到沒有資料拷貝,沒有環境切換,沒有記憶體配置,沒有鎖競爭,那麼我敢保證你的伺服器的效能一定很出色.

資料拷貝Data Copies

本節會有點短,因為大多數人在資料拷貝上吸取過教訓. 幾乎每個人都知道產生資料拷貝是不對的,這點是顯而易見的,在你的職業生涯中, 你很早就會見識過它;而且遇到過這個問題,因為10年前就有人開始說這個詞。對我來說確實如此. 現今,幾乎每個大學課程和幾乎所有how-to文檔中都提到了它. 甚至在某些商業宣傳冊中,"零拷貝" 都是個流行用語. 儘管資料拷貝的壞處顯而易見,但是還是會有人忽視它. 因為產生資料拷貝的代碼常常隱藏很深且帶有偽裝,你知道你所調用的庫或驅動的代碼會進行資料拷貝嗎?答案往往超出想象. 猜猜"程式I/O"在電腦上到底指什麼?雜湊函數是偽裝的資料拷貝的例子,它有帶拷貝的記憶體訪問消耗和更多的計算.
曾經指出雜湊演算法是一種有效"拷貝"似乎能夠被避免,但據我所知,有一些非常聰明的人說過要做到這一點是相當困難的. 如果想真正去除資料拷貝,不管是因為影響了伺服器效能,還是想在駭客大會上展示"零複製"技術,你必須自己跟蹤可能發生資料拷貝的所有地方,而不是輕信宣傳.

有一種可以避免資料拷貝的方法是使用buffer的描述符(或者buffer chains的描述符)來取代直接使用buffer指標,每個buffer描述符應該由以下元素組成:

一個指向buffer的指標和整個buffer的長度

一個指向buffer中真實資料的指標和真實資料的長度,或者長度的位移

以雙向鏈表的形式提供指向其它buffer的指標

一個引用計數

現在,代碼可以簡單的在相應的描述符上增加引用計數來代替記憶體中資料的拷貝. 這種做法在某些條件下表現的相當好,包括在典型的網路通訊協定棧的操作上,但有些情況下這做法也令人很頭大. 一般來說,在buffer chains的開頭和結尾增加buffer很容易,對整個buffer增加引用計數,以及對buffer chains的即刻釋放也很容易. 在chains的中間增加buffer,一塊一塊的釋放buffer,或者對部分buffer增加引用技術則比較困難. 而分割,組合chains會讓人立馬崩潰.

我不建議在任何情況下都使用這種技術,因為當你想在鏈上搜尋你想要的一個塊時,就不得不遍曆一遍描述符鏈,這甚至比資料拷貝更糟糕. 最適用這種技術地方是在程式中大的資料區塊上,這些大資料區塊應該按照上面所說的那樣獨立的分配描述符,以避免發生拷貝,也能避免影響伺服器其它部分的工作. (大資料區塊拷貝很消耗CPU,會影響其它並發線程的運行)

關於資料拷貝最後要指出的是:在避免資料拷貝時不要走極端. 我看到過太多的代碼為了避免資料拷貝,最後結果反而比拷貝資料更糟糕,比如產生環境切換或者一個大的I/O請求被分解了. 資料拷貝是昂貴的,但是在避免它時,是收益遞減的(意思是做過頭了,效果反而不好). 為了除去最後少量的資料拷貝而改變代碼,繼而讓代碼複雜度翻番,不如把時間花在其它方面.

 

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.