<li id="2aw4k"></li>
  • <div id="2aw4k"><tr id="2aw4k"></tr></div>
  • <div id="2aw4k"><tr id="2aw4k"></tr></div>
    <center id="2aw4k"><small id="2aw4k"></small></center><center id="2aw4k"><small id="2aw4k"></small></center>
    首頁»IDC»什么樣的硬件設備在支撐 Stack Overflow?

    什么樣的硬件設備在支撐 Stack Overflow?

    來源:jobbole 發布時間:2014-03-10 閱讀次數:

      我更愿意把Stack Overflow看作是能夠運行于大規模數據下,但本身并不算大規模的(running with scale but not at scale)。意思是我們的網站非常有效率,但至少目前為止,我們的規模還不夠“大”。讓我們通過一些數字來介紹Stack Overflow當前是一個怎樣的規模吧。以下是一些核心的數字,來自于不久前在一整天(24小時)內的統計,準確說是2013年11月12日。這是一個典型的工作日,并且只統計了我們活動的數據中心,也就是我們自己的服務器。那些對CDN節點的請求和流量被排除在外,因為它們并不直接訪問我們的網絡。

    • 負載均衡器接受了148,084,833次HTTP請求
    • 其中36,095,312次是加載頁面
    • 833,992,982,627 bytes (776 GB) 的HTTP流量用于發送
    • 總共接收了286,574,644,032 bytes (267 GB) 數據
    • 總共發送了1,125,992,557,312 bytes (1,048 GB) 數據
    • 334,572,103次SQL查詢(僅包含來自于HTTP請求的)
    • 412,865,051次Redis請求
    • 3,603,418次標簽引擎請求
    • 耗時558,224,585 ms (155 hours) 在SQL查詢上
    • 耗時99,346,916 ms (27 hours) 在Redis請求上
    • 耗時132,384,059 ms (36 hours) 在標簽引擎請求上
    • 耗時2,728,177,045 ms (757 hours) 在ASP.Net程序處理上

      (我覺得應該發表一篇文章介紹我們如何快速采集這些數據,以及為什么值得耗費精力去獲取它們)

      注意以上數字包括了整個Stack Exchange網絡,但那并不是我們全部的。除此之外,這些數字也僅僅來自于我們為了檢測性能而記錄的HTTP請求。“哇,一天有這么多個小時,你們怎么做到的?”我們把這叫做魔法,當然有些人喜歡說成“許多個有多核處理器的服務器”,但我們依然堅持這是魔法。以下是那個數據中心里運行Stack Exchange網絡的設備:

      有圖有真相:

    stack_overflow_1

      我們不僅僅運行網站,旁邊架子上還有一些運行著虛擬機的服務器和其他設備,它們并不直接服務于網站,而是進行部署、域名控制、監控、操作數據庫等其他工作。上面列表中的兩個數據庫服務器之前一直都是用作備份,直到最近才作為只讀的負載(主要用于Stack Exchange API),于是我們可以不需要太多考慮便繼續擴大規模了。Web服務器有兩個分別用于開發和存儲元數據,運行負載非常低。

      核心設備

      如果除去那些多余的設備,以下是Stack Exchange運行需要的(保持目前的性能水平):

    • 2個MS SQL服務器(Stack Overflow在一臺,其他的在另一臺,實際上只需一臺機器運行還能有富余)
    • 2個Web服務器(或許3個吧,不過我有信心2個足矣)
    • 1個Redis服務器
    • 1個標簽引擎服務器
    • 1個ElasticSearch服務器
    • 1個負載均衡器
    • 1個交換機
    • 1個ASA
    • 1個路由器

      (我們真該找個機會嘗試這個配置,關閉部分設備,看看極限在哪)

      現在還有一些虛擬機運行在后臺,執行一些輔助功能,比如域名控制等等。但那都是些相當低負載的任務,我們就不做討論了,這里把重心放在Stack Overflow本身,看看它是怎樣全速加載出頁面的。如果你希望更精確全面,可以增加一個VMware虛擬機進來,用于執行所有的輔助工作。這樣看來并不需要很多機器,但是這些機器的規格通常在云上難以實現,除非你有足夠多的錢。以下是這些“增強型”服務器簡要的配置介紹:

    • 數據庫服務器有384GB內存和1.8TB的SSD硬盤
    • Redis服務器有96GB內存
    • ElasticSearch服務器有196GB內存
    • 標簽引擎服務器有著我們能買得起的最快的處理器
    • 交換機每個端口有10Gb的帶寬
    • Web服務器不是很特別,有32GB內存、2個4核處理器和300GB的SSD硬盤
    • 有些服務器有2個10Gb帶寬的接口(比如數據庫),其他有4個1Gb帶寬的

      20Gb的帶寬太多余了?你還真特么說對了,活動的數據庫服務器平均只利用了20Gb通道中的100-200Mb。然而,像備份、重建等等操作,根據當前內存和SSD硬盤的情況,可以使帶寬完全飽和,所以說這樣設計還是有意義的。

      存儲設備

      我們目前有大約2TB的數據庫存儲(第一個集群有18塊SSD硬盤—— 總共1.63TB,使用1.06TB;第二個集群由4塊SSD硬盤組成—— 總共1.45TB,使用889GB),這是我們在云服務器上需要的(嗯哼,又要吐槽價格了吧),請記住這全部都是SSD硬盤。歸功于存儲器良好的表現,我們數據庫的平均寫入時間是0毫秒,甚至超出我們能度量的精度了。算上內存中的數據以及兩級緩存,Stack Overflow中實際的數據庫讀寫比例是40:60。你沒看錯,60%是寫操作(點此了解讀寫比)。此外,每個Web服務器都有兩塊320GB SSD硬盤組成的RAID1。ElasticSearch在每個區塊大約需要300GB的容量,由于我們會非常頻繁的寫入或重建索引,SSD硬盤在這里是更好的選擇。

      值得注意的是我們擁有一個SAN(存儲區域網絡)連接到核心網絡,那就是 Equal Logic PS6110X,它有24個可熱交換的10K SAS磁盤和2個10Gb的控制器。這個設備僅僅被VM服務器用作共享儲存空間以保證虛擬機高度的可用性,但并不實際支撐網站的運行。換句話說,如果SAN掛掉了,在一段時間內網站甚至無法察覺(只有虛擬機中的域名控制器能感知到)。

      整合到一起

      這所有的設備在一起是為了什么?性能。我們需要很高的性能,這是一個對我們來說很重要的特性。所有站點的首頁都是問題頁面,我們內部把它親切地稱作Question/Show(路由的名字)。在11月12日,這個頁面平均渲染時間是28毫秒,而我們的要求是至多50ms。為了使用戶獲得更好的體驗,我們盡一切可能縮短頁面加載的時間,哪怕只有一毫秒。在和性能有關的問題上,我們所有的開發人員都是“錙銖必較”的,這也有助于我們的網站保持快速響應。以下是一些Stack Overflow上熱門頁面的平均渲染時間,數據還是來自于前面統計的那24小時:

    • Question/Show: 28 ms (2970萬次點擊)
    • User Profiles: 39 ms (170萬次點擊)
    • Question List: 78 ms (110萬次點擊)
    • Home page: 65 ms (100萬次點擊) (這對我們來說已經很慢了,Kevin Montrose正在著手修復這個問題

    憑借對每一次請求的時間線的記錄,我們能夠準確觀察到頁面加載的過程。我們需要這樣的數據,否則難道靠腦補來做決定嗎?有數據在手,我們就可以這樣監控性能:

    stack_overflow_2

      如果你對某個特定頁面的數據感興趣,我也很樂意發布出來。但這里我重點關注渲染時間,因為它表示我們的服務器需要多久來生成一個網頁。網絡傳輸速度是一個完全不同的話題了(盡管不得不承認它也有很大的關系),不過將來我會講到的。

      增長空間

      非常值得一提的是我們這些服務器運行時的使用率都非常低。比如Web服務器的CPU平均使用率為5-15%,內存只使用了15.5GB,網絡流量只有20-40Mb/s;而數據庫服務器CPU平均使用率為5-10%,使用了365GB內存,以及100-200Mb/s的網絡。這使我們能做到幾件重要的事情:在網站規模增大時不至于需要馬上升級設備;當出現問題時(錯誤的查詢、代碼以及攻擊等等,無論是什么樣的問題),我們能保持網站始終不掛;在必要的時候降低功耗。這里有個我們Web層的監控項目

    stack_overflow_3

      利用率如此之低的主要原因是高效的代碼。盡管本文的主題并不是這個,但是高效的代碼對挖掘服務器的性能也有著決定性的作用。做一件非必要的事情所損失的,居然比無所作為還要多——把這引申到代碼中就是說,你需要把它們改進得更高效了。這些損失或者消耗可以是能源、硬件(你需要更多更快的服務器)、開發人員理解代碼更困難(平心而論,這個有兩面性,高效的代碼并不一定那么簡單),以及緩慢的頁面渲染——可能導致用戶更少地瀏覽網站其他頁面甚至再也不訪問你的網站了。低效率代碼帶來的損失可能比你想象的大很多。

      現在我們了解了Stack Overflow運行在怎樣的硬件上,下次可以討論一下為何我們不使用云。

      原文鏈接: SO 團隊成員 Nick Craver   翻譯: 伯樂在線 - 蔣生武

    QQ群:WEB開發者官方群(515171538),驗證消息:10000
    微信群:加小編微信 849023636 邀請您加入,驗證消息:10000
    提示:更多精彩內容關注微信公眾號:全棧開發者中心(fsder-com)
    網友評論(共0條評論) 正在載入評論......
    理智評論文明上網,拒絕惡意謾罵 發表評論 / 共0條評論
    登錄會員中心
    大乐透彩票预测
    <li id="2aw4k"></li>
  • <div id="2aw4k"><tr id="2aw4k"></tr></div>
  • <div id="2aw4k"><tr id="2aw4k"></tr></div>
    <center id="2aw4k"><small id="2aw4k"></small></center><center id="2aw4k"><small id="2aw4k"></small></center>
    <li id="2aw4k"></li>
  • <div id="2aw4k"><tr id="2aw4k"></tr></div>
  • <div id="2aw4k"><tr id="2aw4k"></tr></div>
    <center id="2aw4k"><small id="2aw4k"></small></center><center id="2aw4k"><small id="2aw4k"></small></center>