ab,qps,服務器性能壓力

關於併發用戶數和qps，本身一直被這兩個概念糾結，閱讀了一下相關資料，總結以下：併發用戶數和qps兩個概念沒有直接關係，可是若是要說qps時，必定須要指明是多少併發用戶數下的qps，不然豪無心義，由於單用戶數的40qps和20併發用戶數下的40qps是兩個不一樣的概念。前者說明該應用能夠在一秒內串行執行40個請求，然後者說明在併發20個請求的狀況下，一秒內該應用能處理40個請求

併發鏈接數 = pv / 統計時間 * 頁面衍生鏈接次數 * http響應時間 * 因數 / 其餘web服務器 數量

pv = 併發鏈接數 * 統計時間 * 其餘web服務器 數量/ 頁面衍生鏈接次數 / http響應時間 / 因數

首先介紹一下pv量：
PV(訪問量)：即Page View, 即頁面瀏覽量或點擊量，用戶每次刷新即被計算一次。
UV(獨立訪客)：即Unique Visitor,訪問您網站的一臺電腦客戶端爲一個訪客。00:00-24:00內相同的客戶
端只被計算一次。
IP(獨立IP)：即Internet Protocol,指獨立IP數。00:00-24:00內相同IP地址之被計算一次。

解釋：  統計時間 : pv統計的總時間，單位秒，要計算一天的pv就是86400秒  頁面衍生鏈接次數: 一個html頁面可能會請求好幾回http鏈接，如外部的css, js ,圖片等,能夠估算一下，或者用10,可根據實際狀況改變  http響應時間: 可使用1秒或更少,可根據實際狀況改變  因數: 通常使用5便可,可根據實際狀況計算後推出  其餘web服務器 數量: 其餘web服務器 數量

* 「頁面衍生鏈接次數」，」http響應時間」，」因數」這三個參數要根據實際狀況分析計算後，肯定一個適合的值

推算一下。單臺機器1000併發的狀況下，一天是1,728,000的pv(1秒響應，10個衍生鏈接，因子爲5的狀況下) ======================================================================

例子：

保證天天多少pv的併發鏈接數的計算公式是：  併發鏈接數＝ pv / 統計時間(一天是86400) * 頁面衍生鏈接次數 * http響應時間 * 因數(5) / 其餘web服務器 數量

保證4千萬pv的併發鏈接數：  (40000000pv / 86400秒 * 10個派生鏈接數 * 5秒內響應 * 5倍峯值) / 6臺其餘web服務器 = 19290鏈接數

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

）80~20原則：可是在現實生活中，以上兩種狀況發生的機率很小。根據統計學原理，採用80~20原則計算併發用戶數。 PV*0.8/（8*60*60*0.2）=併發鏈接數，即每秒中有兩個用戶併發。

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

網站訪問統計分析的基礎是獲取網站流量的基本數據，根據網上營銷新觀察的相關文章，網站流量統計指標大體能夠分爲三類，每類包含若干數量的統計指標。具體的網站流量統計是經過不一樣的ip登錄網站來計算的，也就是說。一天內同一臺機器登錄網站的次數不管是多少，在流量統計中只記爲一次有效登錄，這種計算方法能夠較爲科學 的計算出有多少人登錄過該網站，有效的防止了有意的對網站進行刷新從而增長本身網站的點擊率。

網站流量指標

網站流量統計指標經常使用來對網站效果進行評價，主要指標包括：  ·獨立訪問者數量（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秒

para connect per a page: 頁面衍生鏈接次數。一個html頁面可能會請求好幾回http鏈接，如外部的css, js ,圖片等。能夠估算一下

此文來自: 馬開東博客 轉載請註明出處 網址： http://www.makaidong.com

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

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

factor：因數，通常使用5便可。可根據實際狀況計算後推出

web hosts：其餘web服務器 數量

* 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再往多了調一調，以防萬

ps：下面是性能測試的主要概念和計算公式，記錄下：

一．系統吞度量要素：

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

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

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

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

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

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

（不少人常常會把併發數和tps理解混淆）

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

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

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

此文來自: 馬開東博客 轉載請註明出處 網址： http://www.makaidong.com

有一個相對極限值，在應用場景訪問壓力下，只要某一項達到系統最高值，系統的吞吐量就上不去了，若是壓力繼續增大，系統的吞吐量反而會降低，緣由是系統超負荷工做，上下文切換、內存等等其它消耗致使系統性能降低。

決定系統響應時間要素

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

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

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

二．系統吞吐量評估：

咱們在作系統設計的時候就須要考慮cpu運算、io、外部系統響應因素形成的影響以及對系統性能的初步預估。

而一般境況下，咱們面對需求，咱們評估出來的出來qps、併發數以外，還有另一個維度：日pv。

經過觀察系統的訪問日誌發現，在用戶量很大的狀況下，各個時間週期內的同一時間段的訪問流量幾乎同樣。好比工做日的天天早上。只要能拿到日流量圖和qps咱們就能夠推算日流量。

一般的技術方法：

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

        2. 經過壓力測試或者經驗預估，得出最高tps，而後跟進1的關係，計算出系統最高的日吞吐量。b2b中文和淘寶 面對的客戶羣不同，這兩個客戶羣的網絡行爲不該用，他們之間的tps和pv關係比例也不同。

a)淘寶

淘寶 的tps和pv之間的關係一般爲  最高tps：pv大約爲 1 : 11*3600 （至關於按最高tps訪問11個小時，這個是商品詳情的場景，不一樣的應用場景會有一些不一樣）

b) b2b中文站

b2b的tps和pv之間的關係不一樣的系統不一樣的應用場景比例變化比較大，粗略估計在1 : 8個小時左右的關係（09年對offerdetail的流量分析數據）。旺鋪和offerdetail這兩個比例相差很大，多是由於爬蟲暫的比例較高的緣由致使。

在淘寶 環境下，假設咱們壓力測試出的tps爲100，那麼這個系統的日吞吐量=100*11*3600=396萬

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

不管有無思考時間（t_think），測試所得的tps值和併發虛擬用戶數(u_concurrent)、loadrunner讀取的交易響應時間（t_response）之間有如下關係（穩定運行狀況下）：
tps=u_concurrent / (t_response+t_think)。

併發數、qps、平均響應時間三者之間關係