往期性能專題：
1. 前言
在上一篇文章性能專題：一文搞懂性能測試常見指標中，已經(jīng)介紹了，在開展性能測試時，各個維度的常見性能指標項有哪些。
而本文將繼續(xù)介紹，對于軟件性能而言，有哪些指標是需要重點關(guān)注的，并且這些重點關(guān)注的指標又是如何來評估和計算的。
對一個軟件做性能測試時，一般需要關(guān)注哪些性能項呢？
換個角度來思考，我們在軟件設(shè)計、部署、使用、維護中一共有哪些角色的參與，然后再考慮這些角色各自關(guān)注的性能點是什么？
首先，開發(fā)軟件的目的是為了讓用戶使用，我們先站在用戶的角度分析一下，用戶會關(guān)注哪些性能呢。
對于用戶來說，當點擊一個按鈕、鏈接或發(fā)出一條指令開始，到系統(tǒng)把結(jié)果以用戶感知的形式展現(xiàn)出來為止，這個過程所消耗的時間是用戶對這個軟件性能的直觀印象。也就是我們所說的響應時間，當響應時間較小時，用戶體驗是很好的。當然用戶體驗的響應時間包括個人主觀因素和客觀響應時間，在設(shè)計軟件時，我們就需要考慮到如何更好地結(jié)合這兩部分達到用戶最佳的體驗。如：用戶在大數(shù)據(jù)量查詢時，我們可以將先提取出來的數(shù)據(jù)展示給用戶，在用戶看的過程中繼續(xù)進行數(shù)據(jù)檢 索，這時用戶并不知道我們后臺在做什么。
因此，用戶關(guān)注的是用戶操作后軟件的響應時間。
其次，站在管理員或運維的角度考慮，他們一般關(guān)注的性能項有什么，通常來說，包括但不限如下一些指標項：
響應時間
服務器資源使用情況是否合理
應用服務器和數(shù)據(jù)庫資源使用是否合理
系統(tǒng)最多支持多少用戶訪問、系統(tǒng)最大業(yè)務處理量是多少
系統(tǒng)性能可能存在的瓶頸在哪里
更換哪些設(shè)備可以提高性能
系統(tǒng)能否支持7×24小時的業(yè)務訪問
再者，站在開發(fā)（設(shè)計）人員角度去考慮，影響性能的因素，常見有如下一些。
架構(gòu)設(shè)計是否合理
數(shù)據(jù)庫設(shè)計是否合理
代碼是否存在性能方面的問題
系統(tǒng)中是否有不合理的內(nèi)存使用方式
系統(tǒng)中是否存在不合理的線程同步方式
系統(tǒng)中是否存在不合理的資源競爭
在如此多的性能指標項中，最為重要的又有哪些？或者是說在衡量服務性能指標時，最常關(guān)注的幾項性能指標有哪幾個：QPS(TPS)、并發(fā)數(shù)、響應時間。
QPS（TPS）：每秒鐘處理request/事務的數(shù)量。
并發(fā)用戶數(shù)： 系統(tǒng)同時處理的request/事務的用戶數(shù)量。
響應時間（Response Time，RT）： 可以理解為服務器處理響應的耗時，一般取平均響應時間。
下面將對QPS(TPS)、并發(fā)數(shù)、響應時間幾項最主要的指標評估方法進行介紹，別急，且往下看。
1. 提及并發(fā)用戶數(shù)，如何理解什么才算是有效的并發(fā)用戶？
并發(fā)用戶：指的是現(xiàn)實系統(tǒng)中操作業(yè)務的用戶，在性能測試工具中，一般稱為虛擬用戶數(shù)(Virutal User)。
需要注意的是，并發(fā)用戶跟注冊用戶、在線用戶有很大差別的，并發(fā)用戶一定會對服務器產(chǎn)生壓力的，而在線用戶只是 ”掛” 在系統(tǒng)上，對服務器不產(chǎn)生壓力，注冊用戶一般指的是數(shù)據(jù)庫中存在的用戶。
并發(fā)用戶這些用戶的最大特征是和服務器會產(chǎn)生交互，這種交互既可以是單向的傳輸數(shù)據(jù)，也可以是雙向的傳送數(shù)據(jù)。
2.并發(fā)用戶數(shù)常見的評估方法
對于已有系統(tǒng)來說，評估并發(fā)用戶數(shù)，可以從如下幾個方面去做數(shù)據(jù)參考。
1. 系統(tǒng)用戶數(shù)
2. 在線用戶數(shù)
3. 并發(fā)用戶數(shù)
一般來說，可選取高峰時刻，在一定時間內(nèi)使用系統(tǒng)的人數(shù)，這些人數(shù)可認為是在線用戶數(shù)，而并發(fā)用戶數(shù)可以取其中8%~15%的比例基數(shù)，例如在1個小時內(nèi)，使用系統(tǒng)的在線用戶數(shù)為10萬，那么取8%~15%（即8000~1.5萬）作為并發(fā)用戶數(shù)就基本足夠了。
當然，網(wǎng)上也流行另一種并發(fā)用戶數(shù)評估計算方式（可供參考）
它是由幾項因素來決定的：
登錄系統(tǒng)的用戶數(shù)量（n），可以理解為平均每天訪問用戶數(shù)。
用戶從登錄系統(tǒng)到退出系統(tǒng)的時間間隔（L），可以理解為一天內(nèi)用戶從登錄到退出系統(tǒng)的時間間隔。
被考察的時間長度（T），可以理解為一天內(nèi)有多長時間有用戶訪問系統(tǒng)
利用經(jīng)驗公式估算系統(tǒng)的平均并發(fā)用戶數(shù)和峰值數(shù)據(jù)，方法可供參考（并不一定準確）：
平均并發(fā)用戶數(shù)為： C = n*L/T
并發(fā)用戶數(shù)峰值: C' = C + 3*√C
> 其中√為根號
例如：某系統(tǒng)A，有3000個用戶，平均每天大概有400個用戶要訪問該系統(tǒng)，對于一個典型用戶來說，一天之內(nèi)用戶從登陸到退出的平均時間為4小時，而在一天之內(nèi)，用戶只有在8小時之內(nèi)會使用該系統(tǒng)。那么，
平均并發(fā)用戶數(shù)為：C = 400*4/8 = 200
并發(fā)用戶數(shù)峰值為：C1 = 200 + 3*√200 = 243
對于新系統(tǒng)來說，如果沒有歷史數(shù)據(jù)作參考，建議通過業(yè)務部門進行評估。
作為一個用戶你可以對吞吐量（QPS、TPS）、并發(fā)用戶數(shù)這些毫不關(guān)心，但響應時間卻是用戶感受系統(tǒng)性能的主要體現(xiàn)。從用戶角度來說，軟件性能就是軟件對用戶操作的響應時間。說得更明確一點，對用戶來說，當用戶單擊一個按鈕，發(fā)出一條指令或在web頁面上單擊一個鏈接，從用戶單擊開始到應用系統(tǒng)把本次操作的結(jié)果以用戶能察覺的方式展示出來，這個過程所消耗的時間就是用戶對軟件性能的直觀印象。
響應時間既然對用戶體驗如此重要，那這個時間又是如何評估計算出來的呢？
用一個公式來表示：
響應時間=網(wǎng)絡(luò)傳輸時間（請求）+服務器處理時間（一層或是多層）+網(wǎng)絡(luò)傳輸時間（響應）+頁面前段解析時間
更具體來講：
`響應時間=呈現(xiàn)時間+網(wǎng)絡(luò)傳輸時間+系統(tǒng)處理時間
1. 呈現(xiàn)時間
呈現(xiàn)時間主要是指前端的響應時間，這部分時間主要取決于客戶端而非服務端。當然，這個呈現(xiàn)時間也不能全怪罪客戶端身上！它還和承載它的操作系統(tǒng)有關(guān)，以及電腦硬件比如cpu 、內(nèi)存有關(guān)。
2. 網(wǎng)絡(luò)傳輸時間
千萬不要忽視數(shù)據(jù)傳輸時間。試想一下，如果你要寄信給你一個遠方的朋友，你想是什么影響你將信息傳遞給遠方的朋友？不是你寫信的過程（如果你寫的信不像書一樣厚的話），也不是你朋友讀信的過程，而是送信的過程。
你的帶寬是多少？有沒有考慮網(wǎng)絡(luò)延遲？ 互聯(lián)網(wǎng)是個網(wǎng)，就是算是相同的起點與終點，它有可能走的不同的路線。
這也是為什么我們在一般做性能測試時，一般要強調(diào)要在局域網(wǎng)中進行。
3. 系統(tǒng)處理時間
在進行性能測試時，呈現(xiàn)時間和數(shù)據(jù)傳輸時間通常都是我們很難控制的，用戶使用的電腦千差萬別，用戶的網(wǎng)絡(luò)狀況也是千差萬別。我們唯一能控制的就是將系統(tǒng)的處理請求的時間縮到最短。
如果我們對系統(tǒng)處理進行分解的話，它又是一個非常龐大與復雜的過程。包括了語言、語言框架、中間件，數(shù)據(jù)庫、系統(tǒng)架構(gòu)以及服務器系統(tǒng)等。
現(xiàn)在的測試工具一般都屏蔽呈現(xiàn)過程，只是模擬多用戶并發(fā)請求，計算用戶得到響應的時間，也不會將服務器的每個響應都向客戶端呈現(xiàn)。
對于數(shù)據(jù)傳輸?shù)膯栴}，這也是我要強調(diào)的性能測試要在局域網(wǎng)中進行，在局域網(wǎng)中一般不會受到數(shù)據(jù)帶寬的限制。所以，可以對數(shù)據(jù)的傳輸時間忽略不計。
關(guān)于響應時間，要特別說明的一點是，對客戶來說，該值是否能夠被接受是帶有一定的用戶主觀色彩，也就是說，響應時間的“長”和“短”沒有絕對的區(qū)別。
在互聯(lián)網(wǎng)行業(yè)對于用戶響應時間，有一個普遍的標準：2/5/10秒原則。也就是說，在2秒之內(nèi)給客戶響應被用戶認為是“非常有吸引力”的用戶體驗。在5秒之內(nèi)響應客戶被認為“比較不錯”的用戶體驗，在10秒內(nèi)給用戶響應被認為“糟糕”的用戶體驗。如果超過10秒還沒有得到響應，那么大多用戶會認為這次請求是失敗的。這里我們還要考慮一個使用頻率的因素。如果一個功能，一個月才用上一次，并且要求返回的結(jié)果也并非實時的，那么即便慢一些，對于用戶來講，也是可接受的。
系統(tǒng)吞吐量指單位時間內(nèi)系統(tǒng)處理用戶的請求數(shù)。從業(yè)務角度看，吞吐量可以用：請求數(shù)/秒、頁面數(shù)/秒、人數(shù)/天或處理業(yè)務數(shù)/小時等單位來衡量，從網(wǎng)絡(luò)角度看，吞吐量可以用：字節(jié)/秒來衡量
對于交互式應用來說，吞吐量指標反映的是服務器承受的壓力，他能夠說明系統(tǒng)的負載能力。以不同方式表達的吞吐量可以說明不同層次的問題，例如，以字節(jié)數(shù)/秒方式可以表示主要受網(wǎng)絡(luò)基礎(chǔ)設(shè)施、服務器架構(gòu)、應用服務器制約等方面的瓶頸；已請求數(shù)/秒的方式表示主要是受應用服務器和應用代碼的制約體現(xiàn)出的瓶頸。
QPS：全名 Queries Per Second，意思是“每秒查詢率”，是一臺服務器每秒能夠響應的查詢次數(shù)，簡單的說，QPS = req/sec = 請求數(shù)/秒。比如執(zhí)行了select操作，相應的QPS就會增加，它代表的是服務器的機器的性能最大吞吐能力。
計算QPS的常用公式：
QPS（TPS）= 并發(fā)數(shù)/平均響應時間
另外，關(guān)于峰值QPS計算方式，一般也可參照2/8原則（供參考，并非一定）：
原理：每天80%的訪問集中在20%的時間里，這20%時間叫做峰值時間
公式：( 總PV數(shù) * 80% ) / ( 每天秒數(shù) * 20% ) = 峰值時間每秒請求數(shù)(QPS)
問：每天300w PV 的在單臺機器上，這臺機器需要多少Q(mào)PS？
答：( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)
TPS即 Transactions Per Second 的縮寫，指每秒處理的事務數(shù)量。一個事務是指一個客戶機向服務器發(fā)送請求然后服務器做出回應的過程。
TPS 的過程包括：客戶端請求服務端、服務端內(nèi)部處理、服務端返回客戶端。
關(guān)于TPS的獲取評估方式，對于已有系統(tǒng)來說：可選取高峰時刻，在一定時間內(nèi)（如3-10分鐘），獲取系統(tǒng)總業(yè)務量，計算單位時間（秒）內(nèi)完成的筆數(shù)，乘以2-5倍作為峰值的TPS，例如峰值3分鐘內(nèi)處理訂單18萬筆，平均TPS是1000，峰值TPS可以是2000-5000。
對于新系統(tǒng)來說，因為沒有歷史數(shù)據(jù)作參考，一般建議通過業(yè)務部門進行評估。
QPS和TPS之間的區(qū)別，也是很多新手剛接觸時容易搞混的，那他們之間到底有什么區(qū)別和聯(lián)系。
一般來說，QPS基本類似于TPS，但不同的是，對于一個頁面的一次訪問，會形成一個TPS；但一次頁面請求，可能產(chǎn)生多次對服務器的請求，服務器對這些請求，就會計入“QPS”之中。
如果是對一個接口（單場景）壓測，且這個接口內(nèi)部不會再去請求其它接口，那么TPS=QPS。
例如：訪問一個 Index 頁面會請求服務器 3 次，包括一次 html，一次 css，一次 js，那么訪問這一個頁面就會產(chǎn)生一個“TPS”，產(chǎn)生三個“QPS”。
對于衡量單個接口服務的處理能力，一般采用QPS比較多，一般如果衡量事務業(yè)務場景的處理能力一般則采用TPS。
注：Jmeter聚合報告中，Throughput是用來衡量吞吐量，通常是由TPS來表示。
一個系統(tǒng)處理性能能力通常由QPS（TPS）、并發(fā)數(shù)兩個因素決定，每套系統(tǒng)這兩個值都有一個相對極限值，在應用場景訪問壓力下，只要某一項達到系統(tǒng)最高值，系統(tǒng)的吞吐量就上不去了，如果壓力繼續(xù)增大，系統(tǒng)的吞吐量反而會下降，原因是系統(tǒng)超負荷工作，上下文切換、內(nèi)存等其它消耗導致系統(tǒng)性能下降。
影響系統(tǒng)響應時間由CPU運算、IO、外部系統(tǒng)響應等因素組成。一個系統(tǒng)的吞度量（承壓能力）與request對CPU的消耗、外部接口、IO等緊密關(guān)聯(lián)，單個reqeust 對CPU消耗越高，外部系統(tǒng)接口、IO影響速度越慢，系統(tǒng)吞吐能力越低，反之越高。
最后，幾點小結(jié)和建議：
系統(tǒng)的性能一般由TPS決定，跟并發(fā)用戶數(shù)沒有太大直接關(guān)系。
系統(tǒng)的最大TPS是一定的（在一個范圍內(nèi)），但并發(fā)用戶數(shù)不一定，可以調(diào)整。
建議性能測試的時候，不要設(shè)置過長的思考時間，以最壞的情況下對服務器施壓。
一般情況下，大型系統(tǒng)（業(yè)務量大、機器多）做壓力測試，10000～50000個用戶并發(fā)，中小型系統(tǒng)做壓力測試，5000個用戶并發(fā)比較常見。
通過系統(tǒng)的監(jiān)控工具，發(fā)現(xiàn)系統(tǒng)的性能瓶頸，通常會發(fā)生性能瓶頸的地方有CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)、數(shù)據(jù)庫等，而緩存系統(tǒng)容易發(fā)生瓶頸的地方是內(nèi)存，儲存型系統(tǒng)則是I/O。
