你想建設一個能承受500萬PV/天天的網站嗎？

 　　(若是感受有幫助，請幫忙點推薦，添加關注，謝謝！你的支持是我不斷更新文章的動力。本博客會逐步推出一系列的關於大型網站架構、分佈式應用、設計模式、架構模式等方面的系列文章)

　　你想建設一個能承受500萬PV/天天的網站嗎？ 500萬PV是什麼概念？服務器每秒要處理多少個請求才能應對？若是計算呢？ 

PV是什麼：

　　PV是page view的簡寫。PV是指頁面的訪問次數，每打開或刷新一次頁面，就算作一個pv。 

計算模型： 
　　每臺服務器每秒處理請求的數量=((80%*總PV量)/(24小時*60分*60秒*40%)) / 服務器數量。

　　其中關鍵的參數是80%、40%。表示一天中有80%的請求發生在一天的40%的時間內。24小時的40%是9.6小時，有80%的請求發生一天的9.6個小時當中（很適合互聯網的應用，白天請求多，晚上請求少）。 

 

      簡單計算的結果：
　　((80%*500萬)/(24小時*60分*60秒*40%))/1 = 115.7個請求/秒 
　　((80%*100萬)/(24小時*60分*60秒*40%))/1 = 23.1個請求/秒 
初步結論： 
　　如今咱們在作壓力測試時，就有了標準，若是你的服務器一秒能處理115.7個請求，就能夠承受500萬PV/天天。若是你的服務器一秒能處理23.1個請求，就能夠承受100萬PV/天天。 

留足餘量：

　　以上請求數量是均勻的分佈在白天的9.6個小時中，但實際狀況並不會這麼均勻的分佈，會有高峯有低谷。爲了應對高峯時段，應該留一些餘地，最少也要x2倍，x3倍也不爲過。

　　　　115.7個請求/秒 *2倍=231.4個請求/秒

　　　　115.7個請求/秒 *3倍=347.1個請求/秒

　　　　23.1個請求/秒 *2倍=46.2個請求/秒

　　　　23.1個請求/秒 *3倍=69.3個請求/秒 

最終結論：

　　若是你的服務器一秒能處理231.4--347.1個請求/秒，就能夠應對平均500萬PV/天天。

　　若是你的服務器一秒能處理46.2--69.3個請求，就能夠應對平均100萬PV/天天。 

說明：

　　這裏說明每秒N個請求，就是QPS。由於我關心的是應用程序處理業務的能力。 

 

實際經驗：

　　1、根據實際經驗，採用兩臺常規配置的機架式服務器，配置是很常見的配置，例如一個4核CPU+4G內存+服務器SAS硬盤。

　　2、我的武斷的認爲在服務器CPU領域Intel的CPU要優於AMD的CPU，有反對的就反對吧，我都說我武斷了(請看CPU性能比較)，不要太相信AMD的廣告，比較CPU性能簡單辦法就是比價格，不要比頻率與核心數，價格相差很少的性能也相差很少。

　　3、硬盤的性能很重要，由其是數據庫服務器。通常的服務器都配1.5萬轉的SAS硬盤，高級一點的能夠配SSD固態硬盤，性能會更好。最最最最重要的指標是「隨機讀寫性能」而不是「順序讀寫性能」。（本例仍是配置最多見的1.5萬轉的SAS硬盤吧）

　　4、一臺服務器跑Tomcat運行j2ee程序,一臺服務器跑MySql數據庫,程序寫的中等水平(這個真的很差量化)，是論壇類型的應用(總有回帖,不太容易作緩存,也沒法靜態化)。

　　5、以上軟硬件狀況下，是能夠承受100萬PV/天天的。(已留有餘量應對忽然的訪問高峯)

 

注意機房的網絡帶寬：

　　有人說以上條件我都知足了，但實際性能仍是達不到目標。這時請注意你對外的網絡的帶寬，在國內服務器便宜但帶寬很貴，極可能你在機房是與你們共享一條100M的光纖，實際每一個人可分到2M左右帶寬。再好一點5M,再好一點雙線機房10M獨享，這已經很貴了（北京價格）。

　　一天總流量：每一個頁面20k字節*100萬個頁面/1024=19531M字節=19G字節，

　　19531M/9.6小時=2034M/小時=578K字節/s   若是請求是均勻分佈的，須要5M（640K字節）帶寬（5Mb=640KB 注意大小寫，b是位，B是字節，差了8倍），但全部請求不多是均勻分佈的，當有高峯時5M帶寬必定不夠，X2倍就是10M帶寬。10M帶寬基本能夠知足要求。

　　以上是假設每一個頁面20k字節，基本不包含圖片，要是包含圖片就更大了，10M帶寬也不能知足要求了。你自已計算吧。（全文完）

 

 

附：性能測試基本概念
--------------------------------------------------------------------------------------- 
基本概念： 
　　Throughput(吞吐量)：按照常規理解網絡吞吐量表示在單位時間內經過網卡數據量之和，其中即包括本機網卡發送出去的數據量也包括本機網卡接收到的數據量。 一個100Mb(位)的雙工網卡，最大發送數據的速度是12.5M字節/s ，最大接收數據的速度是12.5M字節/s， 能夠 同時 收發 數據。 
　　併發用戶數：是同時執行操做的用戶(線程數)。 
　　響應時間：從請求發出到收到響應花費的時間 。
　　QPS - Queries Per Second  每秒處理的查詢數(若是是數據庫，就至關於讀取)
　　TPS - Transactions Per Second  每秒處理的事務數(若是是數據庫，就至關於寫入、修改)
　　IOPS，每秒磁盤進行的I/O操做次數

例如對某個數據庫測試，分開兩次測QPS與TPS。
　　QPS（讀取）值老是高於TPS(寫、改)，而且有倍率關係，由於：
　　1、數據庫對查詢可能有緩存。
　　2、機械硬盤或SSD硬盤的讀就是比寫快。 
--------------------------------------------------------------------------------------- 
JMeter測試參數說明： 
　　Label：每個測試單元的名字。 
　　#Samples：表示一個測試單元一共發出了多少個請求。 
　　Average：平均響應時間——默認狀況下是單個 Request 的平均響應時間，當使用了 Transaction Controller 時，也能夠以Transaction 爲單位顯示平均響應時間。，不重要。 
　　Median：中位數，也就是 50％ 用戶的響應時間，若是把響應時間從小到大順序排序，那麼50％的請求的響應時間在這個範圍以內。重要。 
　　90% Line：90％ 用戶的響應時間，若是把響應時間從小到大順序排序，那麼90％的請求的響應時間在這個範圍以內。重要 。 
　　Min：最小響應時間，不重要。 
　　Max：最大響應時間，出現概率只不過是千分之一甚至萬分之一，不重要。 
　　Error%：本次測試中出現錯誤的請求的數量 
　　Throughput：吞吐量——默認狀況下表示每秒完成的請求數（Request per Second），當使用了 Transaction Controller 時，也能夠表示相似 LoadRunner 的 Transaction per Second 數 
　　KB/Sec：每秒從服務器端接收 到的數據量(只是接收)，至關於LoadRunner中的Throughput/Sec 
--------------------------------------------------------------------------------------- 
loadrunner測試參數說明： 
　　響應時間： 取90%值，若是把響應時間從小到大順序排序，那麼90％的請求的響應時間在這個範圍以內。重要。 
　　每秒點擊數 ：hits per Second,每秒鐘向服務器提交請求的數量。 
　　TPS： Transaction per Second ，每秒事務數，一個事務是指一個客戶機向服務器發送請求而後服務器作出反應的過程 
　　Throughput（吞吐量）： Loadrunner記錄的Throughput是接收到服務器返回的全部字節數之和，與本地發出的字節數無關。 
　　Throughput/Sec： 每秒的吞吐量。 
　　對於BS架構的通常分析 響應時間、點擊率、吞吐量、TPS（每秒事務數）。 
　　對於CS架構的通常分析 TPS（每秒事務數）