ab,qps,伺服器性能壓力

關于并發使用者數和qps，自己一直被這兩個概念糾結，閱讀了一下相關資料，總結如下：并發使用者數和qps兩個概念沒有直接關系，但是如果要說qps時，一定需要指明是多少并發使用者數下的qps，否則豪無意義，因為單使用者數的40qps和20并發使用者數下的40qps是兩個不同的概念。前者說明該應用可以在一秒内串行執行40個請求，而後者說明在并發20個請求的情況下，一秒内該應用能處理40個請求

首先介紹一下pv量：

PV(通路量)：即Page View, 即頁面浏覽量或點選量，使用者每次重新整理即被計算一次。

UV(獨立訪客)：即Unique Visitor,通路您網站的一台電腦用戶端為一個訪客。00:00-24:00内相同的客戶

端隻被計算一次。

IP(獨立IP)：即Internet Protocol,指獨立IP數。00:00-24:00内相同IP位址之被計算一次。

* “頁面衍生連接配接次數”，”http響應時間”，”因數”這三個參數要根據實際情況分析計算後，确定一個适合的值

推算一下。單台機器1000并發的情況下，一天是1,728,000的pv(1秒響應，10個衍生連接配接，因子為5的情況下) ======================================================================

例子：

面試時，面試官問道：1億個pv，如何确定并發使用者數？  一時想不起來具體的公式，就記得80/20原則，就回答了一些。又說了一些原來我們公司會提供峰值的方法，确定最後施壓的使用者數。

）80~20原則：但是在現實生活中，以上兩種情況發生的機率很小。根據統計學原理，采用80~20原則計算并發使用者數。 PV*0.8/（8*60*60*0.2）=并發連接配接數，即每秒中有兩個使用者并發。

網站流量是指什麼? ip和pv呢？  通常說的網站流量（traffic）是指網站的通路量，是用來描述通路一個網站的使用者數量以及使用者所浏覽的網頁數量等名額，常用的統計名額包括網站的獨立使用者數量、總使用者數量（含重複通路者）、網頁浏覽數量、每個使用者的頁面浏覽數量、使用者在網站的平均停留時間等。

網站流量名額

網站流量統計名額常用來對網站效果進行評價，主要名額包括：  ·獨立通路者數量（unique visitors）；  ·重複通路者數量（repeat visitors）  ·頁面浏覽數（page views）；  ·每個通路者的頁面浏覽數（page views per user）；  ·某些具體檔案/頁面的統計名額，如頁面顯示次數、檔案下載下傳次數等。

ip 是使用不同ip上網的人通路你網站的人數，也就是上面的獨立通路者數量。  一般來說是24小時同一ip不重複記錄的, 也應該24小時不重複記錄。（其實ip也不一定就是獨立通路者數量，因為有的使用者是公用一個ip的,但大緻上可以認為就是今日的獨立通路者數量。）

pv 則是上面的頁面浏覽數，是指這些通路者一共浏覽了多少次你網站的頁面，他是會重複記錄的，你點這個網站10個頁面，他就會記錄10次。

是以pv一定是>=ip的，如一個網站今天的流量統計是100ip 200pv就是說今天有大緻100個獨立通路者，一共通路了200次頁面，平均每個使用者通路頁面數量是 pv/ip=2 ，一般來說這個數字越大說明網站内容越吸引使用者，但也和網站本身的頁面有關。

吞吐量（tps)＝活動的使用者數/響應時間  活動使用者＝并發使用者*[響應時間/（響應時間+思考時間）]  吞吐量（tps)=并發使用者/（響應時間+思考時間）  由此推出：  并發使用者＝活動使用者+吞吐量*思考時間  并發使用者＝活動使用者*（1+思考時間/響應時間）  并發使用者＝吞吐量*（響應時間+思考時間）

并發連接配接數與pv的換算公式  oncurrent connections＝pv / seconds *（para connect per a page) * (time to react) * (factor) / (web hosts)

pv = concurrent connections * seconds * (web hosts)/ (para connect per a page)/ (time to react)/ (factor)

concurrent connections：并發連接配接數

seconds: pv統計的總時間，機關秒，要計算一天的pv就是86400秒

，或者用10。可根據實際情況改變

time to react：http響應時間，可以使用1秒或更少。可根據實際情況改變

factor：因數，一般使用5即可。可根據實際情況計算後推出

* para connect per a page，time to react，factor這三個參數要根據實際情況分析計算後，确定一個适合的值

推算一下。單台機器1000并發的情況下，一天是1,728,000的pv(1秒響應，10個衍生連接配接，因子為5的情況下)

==================================================================================

術語說明：  qps = req/sec = 請求數/秒

【qps計算pv和機器的方式】

qps統計方式 [一般使用 http_load 進行統計]  qps = 總請求數 / ( 程序總數 * 請求時間 )  qps: 單個程序每秒請求伺服器的成功次數

單台伺服器每天pv計算  公式1：每天總pv = qps * 3600 * 6  公式2：每天總pv = qps * 3600 * 8

伺服器計算  伺服器數量 = ceil( 每天總pv / 單台伺服器每天總pv )

【峰值qps和機器計算公式】

原理：每天80%的通路集中在20%的時間裡，這20%時間叫做峰值時間  公式：( 總pv數 * 80% ) / ( 每天秒數 * 20% ) = 峰值時間每秒請求數(qps)  機器：峰值時間每秒qps / 單台機器的qps = 需要的機器

問：每天300w pv 的在單台機器上，這台機器需要多少qps？  答：( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (qps)

問：如果一台機器的qps是58，需要幾台機器來支援？  答：139 / 58 = 3

ps: 在實際情況中，會把這個考慮的更多一點，就是把qps再往多了調一調，以防萬

一．系統吞度量要素：

  一個系統的吞度量（承壓能力）與request對cpu的消耗、外部接口、io等等緊密關聯。

單個reqeust 對cpu消耗越高，外部系統接口、io影響速度越慢，系統吞吐能力越低，反之越高。

系統吞吐量幾個重要參數：qps（tps）、并發數、響應時間

        qps（tps）：每秒鐘request/事務 數量

        并發數： 系統同時處理的request/事務數

        響應時間：  一般取平均響應時間

（很多人經常會把并發數和tps了解混淆）

了解了上面三個要素的意義之後，就能推算出它們之間的關系：

qps（tps）= 并發數/平均響應時間

        一個系統吞吐量通常由qps（tps）、并發數兩個因素決定，每套系統這兩個值都

有一個相對極限值，在應用場景通路壓力下，隻要某一項達到系統最高值，系統的吞吐量就上不去了，如果壓力繼續增大，系統的吞吐量反而會下降，原因是系統超負荷工作，上下文切換、記憶體等等其它消耗導緻系統性能下降。

決定系統響應時間要素

我們做項目要排計劃，可以多人同時并發做多項任務，也可以一個人或者多個人串行工作，始終會有一條關鍵路徑，這條路徑就是項目的工期。

系統一次調用的響應時間跟項目計劃一樣，也有一條關鍵路徑，這個關鍵路徑是就是系統影響時間；

關鍵路徑是有cpu運算、io、外部系統響應等等組成。

二．系統吞吐量評估：

而通常境況下，我們面對需求，我們評估出來的出來qps、并發數之外，還有另外一個次元：日pv。

通過觀察系統的通路日志發現，在使用者量很大的情況下，各個時間周期内的同一時間段的通路流量幾乎一樣。比如工作日的每天早上。隻要能拿到日流量圖和qps我們就可以推算日流量。

通常的技術方法：

        1. 找出系統的最高tps和日pv，這兩個要素有相對比較穩定的關系（除了放假、季節性因素影響之外）

b) b2b中文站

b2b的tps和pv之間的關系不同的系統不同的應用場景比例變化比較大，粗略估計在1 : 8個小時左右的關系（09年對offerdetail的流量分析資料）。旺鋪和offerdetail這兩個比例相差很大，可能是因為爬蟲暫的比例較高的原因導緻。

這個是在簡單（單一url）的情況下，有些頁面，一個頁面有多個request，系統的實際吞吐量還要小。

無論有無思考時間（t_think），測試所得的tps值和并發虛拟使用者數(u_concurrent)、loadrunner讀取的交易響應時間（t_response）之間有以下關系（穩定運作情況下）：

tps=u_concurrent / (t_response+t_think)。

并發數、qps、平均響應時間三者之間關系

<b></b>

<b>     本文轉自yzy121403725 51CTO部落格，原文連結：http://blog.51cto.com/lookingdream/1833448</b><b>，如需轉載請自行聯系原作者</b>