QPS

原理：每天80%的訪問集中在20%的時間里，這20%時間叫做峰值時間。

公式：( 總PV數 * 80% ) / ( 每天秒數 * 20% ) = 峰值時間每秒請求數(QPS) 。

機器：峰值時間每秒QPS / 單臺機器的QPS = 需要的機器 。

每天300w PV 的在單臺機器上，這臺機器需要多少QPS？

( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)。

一般需要達到139QPS，因為是峰值。

QPS?

每秒查詢率QPS是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標準。

每秒查詢率

因特網上，經常用每秒查詢率來衡量域名系統服務器的機器的性能，其即為QPS。

對應fetches/sec，即每秒的響應請求數，也即是最大吞吐能力。

計算機語言

一種計算機編程語言。用于數據分析和報表產出。運作的平臺是MRDCL。支持的數據文件包括ASC格式和CSI格式。

其中CSI格式為QPS獨有數據格式。是極其專業的用于數據分析、數據清理和報表產出的語言，目前應用最廣的是市場調研行業。中國國內運用的相對比較少。

開發的原因，需要對吞吐量（TPS）、QPS、并發數、響應時間（RT）幾個概念做下了解，查自百度百科，記錄如下：

1. 響應時間(RT)

響應時間是指系統對請求作出響應的時間。直觀上看，這個指標與人對軟件性能的主觀感受是非常一致的，因為它完整地記錄了整個計算機系統處理請求的時間。由于一個系統通常會提供許多功能，而不同功能的處理邏輯也千差萬別，因而不同功能的響應時間也不盡相同，甚至同一功能在不同輸入數據的情況下響應時間也不相同。所以，在討論一個系統的響應時間時，人們通常是指該系統所有功能的平均時間或者所有功能的最大響應時間。當然，往往也需要對每個或每組功能討論其平均響應時間和最大響應時間。

對于單機的沒有并發操作的應用系統而言，人們普遍認為響應時間是一個合理且準確的性能指標。需要指出的是，響應時間的絕對值并不能直接反映軟件的性能的高低，軟件性能的高低實際上取決于用戶對該響應時間的接受程度。對于一個游戲軟件來說，響應時間小于100毫秒應該是不錯的，響應時間在1秒左右可能屬于勉強可以接受，如果響應時間達到3秒就完全難以接受了。而對于編譯系統來說，完整編譯一個較大規模軟件的源代碼可能需要幾十分鐘甚至更長時間，但這些響應時間對于用戶來說都是可以接受的。

2. 吞吐量(Throughput)

吞吐量是指系統在單位時間內處理請求的數量。對于無并發的應用系統而言，吞吐量與響應時間成嚴格的反比關系，實際上此時吞吐量就是響應時間的倒數。前面已經說過，對于單用戶的系統，響應時間（或者系統響應時間和應用延遲時間）可以很好地度量系統的性能，但對于并發系統，通常需要用吞吐量作為性能指標。

對于一個多用戶的系統，如果只有一個用戶使用時系統的平均響應時間是t，當有你n個用戶使用時，每個用戶看到的響應時間通常并不是n×t，而往往比n×t小很多（當然，在某些特殊情況下也可能比n×t大，甚至大很多）。這是因為處理每個請求需要用到很多資源，由于每個請求的處理過程中有許多不走難以并發執行，這導致在具體的一個時間點，所占資源往往并不多。也就是說在處理單個請求時，在每個時間點都可能有許多資源被閑置，當處理多個請求時，如果資源配置合理，每個用戶看到的平均響應時間并不隨用戶數的增加而線性增加。實際上，不同系統的平均響應時間隨用戶數增加而增長的速度也不大相同，這也是采用吞吐量來度量并發系統的性能的主要原因。一般而言，吞吐量是一個比較通用的指標，兩個具有不同用戶數和用戶使用模式的系統，如果其最大吞吐量基本一致，則可以判斷兩個系統的處理能力基本一致。

3. 并發用戶數

并發用戶數是指系統可以同時承載的正常使用系統功能的用戶的數量。與吞吐量相比，并發用戶數是一個更直觀但也更籠統的性能指標。實際上，并發用戶數是一個非常不準確的指標，因為用戶不同的使用模式會導致不同用戶在單位時間發出不同數量的請求。一網站系統為例，假設用戶只有注冊后才能使用，但注冊用戶并不是每時每刻都在使用該網站，因此具體一個時刻只有部分注冊用戶同時在線，在線用戶就在瀏覽網站時會花很多時間閱讀網站上的信息，因而具體一個時刻只有部分在線用戶同時向系統發出請求。這樣，對于網站系統我們會有三個關于用戶數的統計數字：注冊用戶數、在線用戶數和同時發請求用戶數。由于注冊用戶可能長時間不登陸網站，使用注冊用戶數作為性能指標會造成很大的誤差。而在線用戶數和同事發請求用戶數都可以作為性能指標。相比而言，以在線用戶作為性能指標更直觀些，而以同時發請求用戶數作為性能指標更準確些。

4. QPS每秒查詢率(Query Per Second)

每秒查詢率QPS是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標準，在因特網上，作為域名系統服務器的機器的性能經常用每秒查詢率來衡量。對應fetches/sec，即每秒的響應請求數，也即是最大吞吐能力。 （看來是類似于TPS，只是應用于特定場景的吞吐量）

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

一．系統吞度量要素：

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

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

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

QPS（TPS）：每秒鐘request/事務?數量

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

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

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

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

QPS（TPS）=?并發數/平均響應時間

一個系統吞吐量通常由QPS（TPS）、并發數兩個因素決定，每套系統這兩個值都有一個相對極限值，在應用場景訪問壓力下，只要某一項達到系統最高值，系統的吞吐量就上不去了，如果壓力繼續增大，系統的吞吐量反而會下降，原因是系統超負荷工作，上下文切換、內存等等其它消耗導致系統性能下降。

決定系統響應時間要素

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

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

關鍵路徑是有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、平均響應時間三者之間關系

來源：http://www.cnblogs.com/jackei/

軟件性能測試的基本概念和計算公式

一、軟件性能的關注點

對一個軟件做性能測試時需要關注那些性能呢？

我們想想在軟件設計、部署、使用、維護中一共有哪些角色的參與，然后再考慮這些角色各自關注的性能點是什么，作為一個軟件性能測試工程師，我們又該關注什么？

首先，開發軟件的目的是為了讓用戶使用，我們先站在用戶的角度分析一下，用戶需要關注哪些性能。

對于用戶來說，當點擊一個按鈕、鏈接或發出一條指令開始，到系統把結果已用戶感知的形式展現出來為止，這個過程所消耗的時間是用戶對這個軟件性能的直觀印象。也就是我們所說的響應時間，當相應時間較小時，用戶體驗是很好的，當然用戶體驗的響應時間包括個人主觀因素和客觀響應時間，在設計軟件時，我們就需要考慮到如何更好地結合這兩部分達到用戶最佳的體驗。如：用戶在大數據量查詢時，我們可以將先提取出來的數據展示給用戶，在用戶看的過程中繼續進行數據檢索，這時用戶并不知道我們后臺在做什么。

用戶關注的是用戶操作的相應時間。

其次，我們站在管理員的角度考慮需要關注的性能點。

1、 相應時間

2、 服務器資源使用情況是否合理

3、 應用服務器和數據庫資源使用是否合理

4、 系統能否實現擴展

5、 系統最多支持多少用戶訪問、系統最大業務處理量是多少

6、 系統性能可能存在的瓶頸在哪里

7、 更換那些設備可以提高性能

8、 系統能否支持7×24小時的業務訪問

再次，站在開發（設計）人員角度去考慮。

1、 架構設計是否合理

2、 數據庫設計是否合理

3、 代碼是否存在性能方面的問題

4、 系統中是否有不合理的內存使用方式

5、 系統中是否存在不合理的線程同步方式

6、 系統中是否存在不合理的資源競爭

那么站在性能測試工程師的角度，我們要關注什么呢？

一句話，我們要關注以上所有的性能點。

二、軟件性能的幾個主要術語

1、響應時間：對請求作出響應所需要的時間

網絡傳輸時間：N1+N2+N3+N4

應用服務器處理時間：A1+A3

數據庫服務器處理時間：A2

響應時間=N1+N2+N3+N4+A1+A3+A2

2、并發用戶數的計算公式

系統用戶數：系統額定的用戶數量，如一個OA系統，可能使用該系統的用戶總數是5000個，那么這個數量，就是系統用戶數。

同時在線用戶數：在一定的時間范圍內，最大的同時在線用戶數量。

同時在線用戶數=每秒請求數RPS（吞吐量）+并發連接數+平均用戶思考時間

平均并發用戶數的計算：C=nL / T

其中C是平均的并發用戶數，n是平均每天訪問用戶數（login session），L是一天內用戶從登錄到退出的平均時間（login session的平均時間），T是考察時間長度（一天內多長時間有用戶使用系統）

并發用戶數峰值計算：C^約等于C + 3*根號C

其中C^是并發用戶峰值，C是平均并發用戶數，該公式遵循泊松分布理論。

3、吞吐量的計算公式

指單位時間內系統處理用戶的請求數

從業務角度看，吞吐量可以用：請求數/秒、頁面數/秒、人數/天或處理業務數/小時等單位來衡量

從網絡角度看，吞吐量可以用：字節/秒來衡量

對于交互式應用來說，吞吐量指標反映的是服務器承受的壓力，他能夠說明系統的負載能力

以不同方式表達的吞吐量可以說明不同層次的問題，例如，以字節數/秒方式可以表示數要受網絡基礎設施、服務器架構、應用服務器制約等方面的瓶頸；已請求數/秒的方式表示主要是受應用服務器和應用代碼的制約體現出的瓶頸。

當沒有遇到性能瓶頸的時候，吞吐量與虛擬用戶數之間存在一定的聯系，可以采用以下公式計算：F=VU * R /

其中F為吞吐量，VU表示虛擬用戶個數，R表示每個虛擬用戶發出的請求數，T表示性能測試所用的時間

4、性能計數器

是描述服務器或操作系統性能的一些數據指標，如使用內存數、進程時間，在性能測試中發揮著“監控和分析”的作用，尤其是在分析統統可擴展性、進行新能瓶頸定位時有著非常關鍵的作用。

資源利用率：指系統各種資源的使用情況，如cpu占用率為68%，內存占用率為55%，一般使用“資源實際使用/總的資源可用量”形成資源利用率。

5、思考時間的計算公式

Think Time，從業務角度來看，這個時間指用戶進行操作時每個請求之間的時間間隔，而在做新能測試時，為了模擬這樣的時間間隔，引入了思考時間這個概念，來更加真實的模擬用戶的操作。

在吞吐量這個公式中F=VU * R / T說明吞吐量F是VU數量、每個用戶發出的請求數R和時間T的函數，而其中的R又可以用時間T和用戶思考時間TS來計算：R = T / TS

下面給出一個計算思考時間的一般步驟：

A、首先計算出系統的并發用戶數

C=nL / T F=R×C

B、統計出系統平均的吞吐量

F=VU * R / T R×C = VU * R / T

C、統計出平均每個用戶發出的請求數量

R=u*C*T/VU

D、根據公式計算出思考時間

TS=T/R