系統容量預估

系統容量預估

 

　　前幾天聊過，pv 和併發 的概念，也大概解釋了 併發，帶寬等指標的計算。感興趣的朋友，能夠看看我前面那篇文章：《聊一聊PV和併發》。今天再來聊一聊容量預估。

 

　　電商公司的朋友，，這樣的場景是否似曾相識：

　　　  運營和產品神祕兮兮的跑過來問：

　　　　咱們晚上要作搞個促銷，服務器能抗住麼？若是扛不住，須要加多少臺機器？

　　　　因而，技術一臉懵逼。

 

　　其實，這些都是系統容量預估的問題，容量預估是架構師必備的技能之一。所謂，容量預估其實說白了就是，系統在down掉以前，所能承受的最大流量。這個事技術人員對於系統性能瞭解的重要指標。常見的容量評估包括流量、併發量、帶寬、CPU,內存 ,磁盤等一系列內容。今天就來聊一聊容量預估的問題。

電商總結

電商總結

電商總結（六）系統容量預估

摘要: 前幾天聊過，pv 和併發 的概念，也大概解釋了 併發，帶寬等指標的計算。感興趣的朋友，能夠看看我前面那篇文章：《聊一聊PV和併發》。今天再來聊一聊容量預估。 電商公司的朋友，，這樣的場景是否似曾相識： 運營和產品神祕兮兮的跑過來問： 咱們晚上要作搞個促銷，服務器能抗住麼？若是扛不住，須要加多少臺機器 閱讀全文

posted @  2016-09-07 08:51 章爲忠 閱讀(611) |  評論 (2)  編輯

 

電商總結（五）移動M站建設

摘要: 最近在一直在搞M站，也就是移動web站點。因爲是第一次，也遇到了不少問題，因此把最近了解到的東西總結總結。聊一聊什麼是移動M站，它有啥做用和優點。 也有人會問，M站和APP有什麼不一樣？ 1. APP 直接在用戶的移動設備上，曝光率相對較高。 而M站需打開瀏覽器，輸入地址才能訪問，因此曝光率相對較低。 閱讀全文

posted @  2016-04-18 18:32 章爲忠 閱讀(728) |  評論 (9)  編輯

 

電商總結（四）基於共享存儲的圖片服務器架構

摘要: 在當前這個互聯網的時代，無論何種網站，對圖片的需求量愈來愈大，尤爲在電商網站中，幾乎都會面臨到海量圖片資源的存儲、訪問等相關技術問題。在對圖片服務器的架構，擴展，升級的過程當中，確定也會碰到各類各樣的問題，各類各樣的需求。固然這並不表明，就必須得弄一個特別NB的圖片服務架構，簡單，高效，穩定就行。因此 閱讀全文

posted @  2016-03-08 18:29 章爲忠 閱讀(1128) |  評論 (14)  編輯

 

電商總結（三）構建數據庫的主從架構

摘要: 這段時間，一直在總結電商系統的相關基礎技術和架構，寫了不少東西。可是仍是發現一個很重要，很基礎的方面沒有講到，那就是數據庫讀寫分離的主從架構。可能發展到大型成熟的公司以後，主從架構已經落伍了，取而代之的是更加複雜的數據庫集羣。可是做爲一個小型電商公司，數據庫的主從架構應該是最基礎的。任何大型的系統架 閱讀全文

posted @  2016-03-03 18:24 章爲忠 閱讀(2305) |  評論 (25)  編輯

 

電商總結（二）日誌與監控系統的解決方案

摘要: 前一篇文章聊到了小型電商網站的系統架構，而後有朋友問我，裏面的日誌與監控指的是啥，因此，今天就來聊聊這個問題。 監控系統主要用於服務器集羣的資源和性能監控以及應用異常和性能監控，日誌管理等多維度的性能監控分析。一個完善的監控系統和日誌系統對於一個系統的重要性沒必要我多說，總而言之就一句話，只有實時瞭解 閱讀全文

posted @  2016-02-24 18:21 章爲忠 閱讀(2065) |  評論 (7)  編輯

 

電商總結（一）小型電商網站的架構

摘要: 又是一年年末了，這一年，從傳統軟件行業進入到電商企業，算是一次轉行了吧。剛開始，以爲電商網站沒有什麼技術含量，也沒有什麼門檻，都是一些現有的東西堆積木似的堆出來而已。然而，真正進入到這個行業以後，才發現並非這樣。記得有人說過，好的架構，是演化出來的。電商網站的架構也是如此，如今牛逼的電商網站，看似 閱讀全文

posted @  2016-02-01 18:21 章爲忠 閱讀(3561) |  評論 (21)  編輯

 　　

　　一，幾個重要參數

　　　　  QPS：每秒鐘處理的請求數

       　　 併發量： 系統同時處理的請求數

        　　響應時間：  通常取平均響應時間

　　　　 不少人常常會把併發數和QPS 混淆，理解了上面三個要素的意義以後，就能推算出它們之間的關係：QPS = 併發量 / 平均響應時間

 

　　二，容量評估的步驟與方法

　　　　1：預估總訪問量

　　　　如何知道總訪問量？對於一個運營活動的訪問量評估，或者一個系統上線後PV的評估，有什麼好的方法？

　　　　最簡單的辦法就是：詢問業務方，詢問運營同窗，詢問產品同窗，看產品和運營對這次活動的流量預估。

　　　　不過，業務方對於流量的預估，應該就兩個指標，pv 和 用戶訪問數。技術人員 須要更具這兩個數據，計算其餘相關指標，好比  QPS 等。具體如何計算可參照我前面一篇 pv和併發 的文章。 

 

　　　　2：預估平均QPS

　　　　　　總請求數 = 總PV * 頁面衍生鏈接數

　　　　　　平均QPS = 總請求數 / 總時間

　　　　　　好比：活動落地頁1小時內的總訪問量是30w pv，該落地頁的衍生鏈接數爲30  ,那麼落地頁的平均QPS

　　　　　　(30w * 30) /(60 * 60) = 2500， 

 

　　　　3：預估峯值QPS

　　　　　　系統容量規劃時，不能只考慮平均QPS，而是要抗住高峯的QPS，如何評估峯值QPS呢？

　　　　　　這個要根據實際的業務評估，經過以往的一些營銷活動的 pv 等數據進行預估。通常狀況，峯值QPS大概是均值QPS的3-5倍，日均QPS爲1000，因而評估出峯值QPS爲5000。

 　　　　　　不過，有一些業務例如「秒殺業務」比較難評估業務訪問量，這類業務的容量評估不在此討論。

 

　　　　4：預估系統、單機極限QPS

　　　　　　如何預估一個業務，一個服務器單機的極限QPS呢？

　　　　　　這個性能指標，是服務器，最基本的指標之一，因此沒有其餘的辦法，就是壓力測試。經過壓力測試，算出服務器的單機極限QPS 。

　　　　　　在一個業務上線前，通常都須要進行壓力測試（不少創業型公司，業務迭代很快的系統可能沒有這一步，那就悲劇了），以APP 推送 某營銷活動爲例（預計 日均QPS 1000，峯值QPS 5000），業務場景多是這樣的：

　　　　　　1）經過 APP 推送一個活動消息 

　　　　　　2）運營活動H5落地頁是一個web站點

　　　　　　3）H5落地頁由緩存cache、數據庫db中的數據拼裝而成

 

　　　　　　經過壓力測試發現，web 服務器 單機只能抗住1200的QPS，cache和數據庫db 能抗住併發壓力，（通常來講，1%的流量到數據庫，數據庫120 QPS仍是能輕鬆抗住的，cache的話QPS能抗住，須要評估cache的帶寬，這裏假設cache不是瓶頸），這樣，咱們就獲得了web單機極限的QPS是1200。通常來講，生產系統不會跑滿到極限的，這樣容易影響服務器的壽命和性能，單機線上容許跑到QPS 1200 * 0.8 = 960 。

　　　　　　擴展說一句，經過壓力測試，已經知道web層是瓶頸，則可針對web 相關的作一些調整優化，以提升web 服務器 的單機QPS 。

　　　　　　還有，壓力測試工做中，通常是以具體業務的角度進行壓力測試，關心的是某個具體業務的併發量和QPS。

 

　　　　5：回答最開始那兩個問題　　　　　

　　　　　　須要的機器  = 峯值QPS / 單機極限 QPS 

　　　　　　好了，上述已經獲得了峯值QPS是5000，單機極限QPS是1000，線上部署了3臺服務器：

　　　　　　（1）服務器能抗住麼？ -> 峯值5000，單機1000，線上3臺，扛不住

　　　　　　（2）若是扛不住，須要加多少臺機器？ -> 須要額外2臺，提早預留1臺更好，給3臺保險

 　　三，最後

　　　　　以上，只是我的一些經驗分享，有啥不對的地方，大夥輕點拍磚，有更好的建議歡迎回復，，

 

做者：章爲忠 
出處：http://www.cnblogs.com/zhangweizhong/