Refer to:http://elf8848.iteye.com/blog/967049

你想建設一個能承受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(每秒事務數)

-----------------------------------------------------

Silence, the way to avoid many problems;

Smile, the way to solve many problems;

posted on 2013-05-04 16:00 Chan Chen 閱讀(1214) 評論(0) ?編輯 ?收藏 所屬分類: Architecture

總結

以上是生活随笔為你收集整理的java记录pv,计算500万PV/每天的网站的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。