性能專題：一文搞懂，性能測試名額評估方法

更多測試開發技術幹貨，請關注公衆号：【測試開發技術】

往期性能專題：

開篇：性能測試不可不知的“幹貨” 性能專題：一文搞懂性能測試常見名額

閱讀全文需8.5分鐘。

1. 前言

在上一篇文章

中，已經介紹了，在開展性能測試時，各個次元的常見性能名額項有哪些。

而本文将繼續介紹，對于軟體性能而言，有哪些名額是需要重點關注的，并且這些重點關注的名額又是如何來評估和計算的。

2. 軟體性能的關注點

對一個軟體做性能測試時，一般需要關注哪些性能項呢？

換個角度來思考，我們在軟體設計、部署、使用、維護中一共有哪些角色的參與，然後再考慮這些角色各自關注的性能點是什麼？

首先，開發軟體的目的是為了讓使用者使用，我們先站在使用者的角度分析一下，使用者會關注哪些性能呢。

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

是以，使用者關注的是使用者操作後軟體的響應時間。

其次，站在管理者或運維的角度考慮，他們一般關注的性能項有什麼，通常來說，包括但不限如下一些名額項：

• 響應時間
• 伺服器資源使用情況是否合理
• 應用伺服器和資料庫資源使用是否合理
• 系統最多支援多少使用者通路、系統最大業務處理量是多少
• 系統性能可能存在的瓶頸在哪裡
• 更換哪些裝置可以提高性能
• 系統能否支援7×24小時的業務通路

再者，站在開發（設計）人員角度去考慮，影響性能的因素，常見有如下一些。

• 架構設計是否合理
• 資料庫設計是否合理
• 代碼是否存在性能方面的問題
• 系統中是否有不合理的記憶體使用方式
• 系統中是否存在不合理的線程同步方式
• 系統中是否存在不合理的資源競争

3. 衡量服務性能的關鍵名額及評估方法

在如此多的性能名額項中，最為重要的又有哪些？或者是說在衡量服務性能名額時，最常關注的幾項性能名額有哪幾個：QPS(TPS)、并發數、響應時間。

• QPS（TPS）：每秒鐘處理request/事務的數量。
• 并發使用者數： 系統同時處理的request/事務的使用者數量。
• 響應時間（Response Time，RT）： 可以了解為伺服器處理響應的耗時，一般取平均響應時間。

下面将對QPS(TPS)、并發數、響應時間幾項最主要的名額評估方法進行介紹，别急，且往下看。

3.1 并發使用者數

1. 提及并發使用者數，如何了解什麼才算是有效的并發使用者？

并發使用者：指的是現實系統中操作業務的使用者，在性能測試工具中，一般稱為虛拟使用者數(Virutal User)。

需要注意的是，并發使用者跟注冊使用者、線上使用者有很大差别的，并發使用者一定會對伺服器産生壓力的，而線上使用者隻是 ”挂” 在系統上，對伺服器不産生壓力，注冊使用者一般指的是資料庫中存在的使用者。

并發使用者這些使用者的最大特征是和伺服器會産生互動，這種互動既可以是單向的傳輸資料，也可以是雙向的傳送資料。

2.并發使用者數常見的評估方法

對于已有系統來說，評估并發使用者數，可以從如下幾個方面去做資料參考。

• 1. 系統使用者數
• 1. 線上使用者數
• 1. 并發使用者數

一般來說，可選取高峰時刻，在一定時間内使用系統的人數，這些人數可認為是線上使用者數，而并發使用者數可以取其中8%~15%的比例基數，例如在1個小時内，使用系統的線上使用者數為10萬，那麼取8%~15%（即8000~1.5萬）作為并發使用者數就基本足夠了。

當然，網上也流行另一種并發使用者數評估計算方式（可供參考）

它是由幾項因素來決定的：

登入系統的使用者數量（n），可以了解為平均每天通路使用者數。

使用者從登入系統到退出系統的時間間隔（L），可以了解為一天内使用者從登入到退出系統的時間間隔。

被考察的時間長度（T），可以了解為一天内有多長時間有使用者通路系統

利用經驗公式估算系統的平均并發使用者數和峰值資料，方法可供參考（并不一定準确）：

平均并發使用者數為：

C = n*L/T           

并發使用者數峰值:

C‘ = C + 3*√C           

其中√為根号

例如：某系統A，有3000個使用者，平均每天大概有400個使用者要通路該系統，對于一個典型使用者來說，一天之内使用者從登陸到退出的平均時間為4小時，而在一天之内，使用者隻有在8小時之内會使用該系統。那麼，

C = 400*4/8 = 200

并發使用者數峰值為：

C1 = 200 + 3*√200 = 243

對于新系統來說，如果沒有曆史資料作參考，建議通過業務部門進行評估。

3.2 響應時間

作為一個使用者你可以對吞吐量（QPS、TPS）、并發使用者數這些毫不關心，但響應時間卻是使用者感受系統性能的主要展現。從使用者角度來說，軟體性能就是軟體對使用者操作的響應時間。說得更明确一點，對使用者來說，當使用者單擊一個按鈕，發出一條指令或在web頁面上單擊一個連結，從使用者單擊開始到應用系統把本次操作的結果以使用者能察覺的方式展示出來，這個過程所消耗的時間就是使用者對軟體性能的直覺印象。

響應時間既然對使用者體驗如此重要，那這個時間又是如何評估計算出來的呢？

用一個公式來表示：

響應時間=網絡傳輸時間（請求）+伺服器處理時間（一層或是多層）+網絡傳輸時間（響應）+頁面前段解析時間

更具體來講：

響應時間=呈現時間+網絡傳輸時間+系統處理時間

1. 呈現時間

呈現時間主要是指前端的響應時間，這部分時間主要取決于用戶端而非服務端。當然，這個呈現時間也不能全怪罪用戶端身上！它還和承載它的作業系統有關，以及電腦硬體比如cpu 、記憶體有關。

2. 網絡傳輸時間

千萬不要忽視資料傳輸時間。試想一下，如果你要寄信給你一個遠方的朋友，你想是什麼影響你将資訊傳遞給遠方的朋友？不是你寫信的過程（如果你寫的信不像書一樣厚的話），也不是你朋友讀信的過程，而是送信的過程。

你的帶寬是多少？有沒有考慮網絡延遲？ 網際網路是個網，就是算是相同的起點與終點，它有可能走的不同的路線。

這也是為什麼我們在一般做性能測試時，一般要強調要在區域網路中進行。

3. 系統處理時間

在進行性能測試時，呈現時間和資料傳輸時間通常都是我們很難控制的，使用者使用的電腦千差萬别，使用者的網絡狀況也是千差萬别。我們唯一能控制的就是将系統的處理請求的時間縮到最短。

如果我們對系統處理進行分解的話，它又是一個非常龐大與複雜的過程。包括了語言、語言架構、中間件，資料庫、系統架構以及伺服器系統等。

現在的測試工具一般都屏蔽呈現過程，隻是模拟多使用者并發請求，計算使用者得到響應的時間，也不會将伺服器的每個響應都向用戶端呈現。

對于資料傳輸的問題，這也是我要強調的性能測試要在區域網路中進行，在區域網路中一般不會受到資料帶寬的限制。是以，可以對資料的傳輸時間忽略不計。

關于響應時間，要特别說明的一點是，對客戶來說，該值是否能夠被接受是帶有一定的使用者主觀色彩，也就是說，響應時間的“長”和“短”沒有絕對的差別。

在網際網路行業對于使用者響應時間，有一個普遍的标準：2/5/10秒原則。也就是說，在2秒之内給客戶響應被使用者認為是“非常有吸引力”的使用者體驗。在5秒之内響應客戶被認為“比較不錯”的使用者體驗，在10秒内給使用者響應被認為“糟糕”的使用者體驗。如果超過10秒還沒有得到響應，那麼大多使用者會認為這次請求是失敗的。這裡我們還要考慮一個使用頻率的因素。如果一個功能，一個月才用上一次，并且要求傳回的結果也并非實時的，那麼即便慢一些，對于使用者來講，也是可接受的。

3.3 系統吐吞量（QPSTPS）

系統吞吐量指機關時間内系統處理使用者的請求數。從業務角度看，吞吐量可以用：請求數/秒、頁面數/秒、人數/天或處理業務數/小時等機關來衡量，從網絡角度看，吞吐量可以用：位元組/秒來衡量

對于互動式應用來說，吞吐量名額反映的是伺服器承受的壓力，他能夠說明系統的負載能力。以不同方式表達的吞吐量可以說明不同層次的問題，例如，以位元組數/秒方式可以表示主要受網絡基礎設施、伺服器架構、應用伺服器制約等方面的瓶頸；已請求數/秒的方式表示主要是受應用伺服器和應用代碼的制約展現出的瓶頸。

QPS：全名 Queries Per Second，意思是“每秒查詢率”，是一台伺服器每秒能夠響應的查詢次數，簡單的說，QPS = req/sec = 請求數/秒。比如執行了select操作，相應的QPS就會增加，它代表的是伺服器的機器的性能最大吞吐能力。

計算QPS的常用公式：

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

另外，關于峰值QPS計算方式，一般也可參照2/8原則（供參考，并非一定）：

原理：每天80%的通路集中在20%的時間裡，這20%時間叫做峰值時間

公式：

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

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

答：

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

TPS即 Transactions Per Second 的縮寫，指每秒處理的事務數量。一個事務是指一個客戶機向伺服器發送請求然後伺服器做出回應的過程。

TPS 的過程包括：用戶端請求服務端、服務端内部處理、服務端傳回用戶端。

關于TPS的擷取評估方式，對于已有系統來說：可選取高峰時刻，在一定時間内（如3-10分鐘），擷取系統總業務量，計算機關時間（秒）内完成的筆數，乘以2-5倍作為峰值的TPS，例如峰值3分鐘内處理訂單18萬筆，平均TPS是1000，峰值TPS可以是2000-5000。

對于新系統來說，因為沒有曆史資料作參考，一般建議通過業務部門進行評估。

QPS和TPS之間的差別，也是很多新手剛接觸時容易搞混的，那他們之間到底有什麼差別和聯系。

一般來說，QPS基本類似于TPS，但不同的是，對于一個頁面的一次通路，會形成一個TPS；但一次頁面請求，可能産生多次對伺服器的請求，伺服器對這些請求，就會計入“QPS”之中。

如果是對一個接口（單場景）壓測，且這個接口内部不會再去請求其它接口，那麼TPS=QPS。

例如：通路一個 Index 頁面會請求伺服器 3 次，包括一次 html，一次 css，一次 js，那麼通路這一個頁面就會産生一個“TPS”，産生三個“QPS”。

對于衡量單個接口服務的處理能力，一般采用QPS比較多，一般如果衡量事務業務場景的處理能力一般則采用TPS。

注：Jmeter聚合報告中，Throughput是用來衡量吞吐量，通常是由TPS來表示。

4. 小結

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

影響系統響應時間由CPU運算、IO、外部系統響應等因素組成。一個系統的吞度量（承壓能力）與request對CPU的消耗、外部接口、IO等緊密關聯，單個reqeust 對CPU消耗越高，外部系統接口、IO影響速度越慢，系統吞吐能力越低，反之越高。

最後，幾點小結和建議：

• 系統的性能一般由TPS決定，跟并發使用者數沒有太大直接關系。
• 系統的最大TPS是一定的（在一個範圍内），但并發使用者數不一定，可以調整。
• 建議性能測試的時候，不要設定過長的思考時間，以最壞的情況下對伺服器施壓。
• 一般情況下，大型系統（業務量大、機器多）做壓力測試，10000～50000個使用者并發，中小型系統做壓力測試，5000個使用者并發比較常見。
• 通過系統的監控工具，發現系統的性能瓶頸，通常會發生性能瓶頸的地方有CPU、記憶體、磁盤、網絡、資料庫等，而緩存系統容易發生瓶頸的地方是記憶體，儲存型系統則是I/O。