性能測試

性能測試是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項性能指標進行測試。

按照不同的目標，可以分為負載測試、壓力測試、容量測試、穩定性測試。平時工作中如果不是專業的測試機構，開發人員或者運維人員做的基本上都屬於壓測。

壓力測試是通過確定一個系統的瓶頸或者不能接受的性能點，來獲得系統能提供的最大服務級別的測試。

性能指標

QPS

目前在業界告訴別人我系統的性能指標，比較容易說的就是QPS。QPS有時也說TPS，指的是每秒鐘request/事務。通常有人告訴你他的接口並發3000通常指的就是QPS=3000，可以理解為他的系統1秒鐘接受並處理完畢3000個請求。

QPS的算法就是：完成請求的數量/完成請求所花費的時間

如果10秒的時間內，系統接受到了3000個請求，返回了2000個，剩下1000報錯。它的QPS=2000/10=200個

響應時間

響應時間，從單個請求來看就是服務響應一次請求的花費的時間。但是在性能測試中，單個請求的響應時間並沒有什麽參考價值，通常考慮的是完成所有請求的平均響應時間及中位數時間。

平均響應時間很好理解，就是完成請求花費的總時間/完成的請求總數。但是平均響應時間有一點不靠譜，因為系統的運行並不是平穩平滑的，如果某幾個請求的時間超短或者超長就會導致平均數偏離很多。可以參考讀新聞的平均工資、平均房價等，你就知道為什麽不那麽靠譜了。因此有時候我們會用中位數響應時間。

所謂中位數的意就是把將一組數據按大小順序排列，處在最中間位置的一個數叫做這組數據的中位數 ，這意味著至少有50%的數據低於或高於這個中位數。當然，最為正確的統計做法是用百分比分布統計。也就是英文中的TP – Top Percentile ，TP50的意思在，50%的請求都小於某個值，TP90表示90%的請求小於某個時間。

並發數

並發數是一個特別容易混淆的概念，因為他在各種語境下表示的含義可能並不相同，從性能測試結果的角度來看

並發指的是在某一時間點，服務器正在處理的請求數

但是我們在實際工作中，經常聽到別的說法

舉例來說：

工程師經常說1秒並發2000，其實他指的是QPS=2000。

而一個網站管理員說我們並發1000人，其實指的最大在線人數1000人。在線人數1000人並不意味每個人都同一時間在跟服務器做交互，因此服務器的並發數並未到1000.

運維人員說我設置的tomcat的並發數500，他指的是這個tomcat最多可以調用500個線程同時接受請求。也就是同一時間服務器能達到的最大並發數數是500，但是受限於CPU、OS等其他原因，並發數在實際中達不到這個數值。

性能測試人員說我在LR中設置了並發數3000，指的是他在測試工具中設置3000個並發模擬用戶，只是理論上在單位時間內最多會有3000個的模擬請求到服務器上。但是從客戶端角度出發，客戶端有可能因為CPU、OS、等待時間等等限制，並不能達到此壓力。即使客戶端達到了此壓力，但是從服務器的角度出發，會有排隊機制以及部分請求異常溢出，並不能說服務器的並發就到了3000。

因此性能測試中的並發數指的是一個測試出來的結果計算值，其計算公式是

QPS*平均響應時間

吞吐量

吞吐量，是指在一次性能測試過程中網絡上傳輸的數據量的總和。對於交互式應用來說，吞吐量指標反映的是服務器承受的壓力，在容量規劃的測試中，吞吐量是一個重點關註的指標，因為它能夠說明系統級別的負載能力，另外，在性能調優過程中，吞吐量指標也有重要的價值。如一個大型工廠，他們的生產效率與生產速度很快，一天生產10W噸的貨物，結果工廠的運輸能力不行，就兩輛小型三輪車一天拉2噸的貨物，比喻有些誇張，但我想說明的是這個運輸能力是整個系統的瓶頸。

提示，用吞吐量來衡量一個系統的輸出能力是極其不準確的，用個最簡單的例子說明，一個水龍頭開一天一夜，流出10噸水；10個水龍頭開1秒鐘，流出0.1噸水。當然是一個水龍頭的吞吐量大。你能說1個水龍頭的出水能力是10個水龍頭的強？所以，我們要加單位時間，看誰1秒鐘的出水量大。這就是吞吐率。

最大並發量

在理解了上述幾個指標之後，性能測試的目的就變成了在特定的條件下（固定硬件設備，通常要排除網絡瓶頸），尋找系統的最大並發量的過程。當並發數增大到一定的程度，系統反應時間還在可以接受的範圍之內，服務並沒有出現失敗，或者失敗率在可接受的範圍內，如果超過此並發量，系統的指標變得不可接受，則認為這個值是系統的最大並發量。

最大並發量的應用

系統的最大並發量只是一個技術上的理論值，往往在技術團隊內吹吹牛，而鮮有業務同學感興趣。在你對自己1000個最大並發量感到沾沾自喜的時候，客戶質問：“你說的1000並發到底能承載多少個用戶呀？”。這時你往往懵逼了，這時你往往要問客戶一句：”你問的是註冊用戶，還是同時在線用戶？“。現實的情況是單個功能模塊的QPS及最大並發數，往往很難估算出全站的業務含義上的用戶量，現實生活比計算機機房模擬的環境要復雜的多，需要考慮網絡環境、用戶對各個功能點的使用率、用戶的操作習慣行為等，即使你使用LR等復雜的測試模擬工具，對不同的功能模塊進行了綜合的測試，往往也只能得出一個估算的值，而且你往往遇到的最大的問題是你沒有那麽強的扮演成千上萬模擬客戶端的測試機，即使你有，你往往又沒有那麽寬的帶寬，在壓力上去之後，網絡首先成為了瓶頸（這也就是為什麽阿裏之類的PTS等測試服務存在的原因）。

不過幸運的是，我們往往並不用得到特別精確的值來服務我們的業務，往往是個大概的值就可以了，所以我們還是可以根據一些經驗估算，比如按照之前項目的PV，按照自己的想法對每個模塊加權計算。甚至於可以拿日常的PV數除一下高峰持續時間得到日常的QPS，再以最大的QPS估算能夠支持的最大PV數，再推出UV數。

有個帖子貼了常見WEB網站的QPS等級分類，可以參考下

http://www.cnblogs.com/yiwd/p/3711677.html

按照帖子的描述：90%的網站其實都是在前兩級別浮動

如何嚴謹地做性能測試

以下內容來自著名博主：左耳朵耗子

原文參見：https://coolshell.cn/articles/17381.html

一般來說，性能測試要統一考慮這麽幾個因素：Thoughput吞吐量，Latency響應時間，資源利用（CPU/MEM/IO/Bandwidth…），成功率，系統穩定性。

下面的這些性能測試的方式基本上來源自我的老老東家湯森路透，一家做real-time的金融數據系統的公司。

一，你得定義一個系統的響應時間latency，建議是TP99，以及成功率。比如路透的定義：99.9%的響應時間必需在1ms之內，平均響應時間在1ms以內，100%的請求成功。

二，在這個響應時間的限制下，找到最高的吞吐量。測試用的數據，需要有大中小各種尺寸的數據，並可以混合。最好使用生產線上的測試數據。

三，在這個吞吐量做Soak Test，比如：使用第二步測試得到的吞吐量連續7天的不間斷的壓測系統。然後收集CPU，內存，硬盤/網絡IO，等指標，查看系統是否穩定，比如，CPU是平穩的，內存使用也是平穩的。那麽，這個值就是系統的性能

四，找到系統的極限值。比如：在成功率100%的情況下（不考慮響應時間的長短），系統能堅持10分鐘的吞吐量。

五，做Burst Test。用第二步得到的吞吐量執行5分鐘，然後在第四步得到的極限值執行1分鐘，再回到第二步的吞吐量執行5鐘，再到第四步的權限值執行1分鐘，如此往復個一段時間，比如2天。收集系統數據：CPU、內存、硬盤/網絡IO等，觀察他們的曲線，以及相應的響應時間，確保系統是穩定的。

六、低吞吐量和網絡小包的測試。有時候，在低吞吐量的時候，可能會導致latency上升，比如TCP_NODELAY的參數沒有開啟會導致latency上升（詳見TCP的那些事），而網絡小包會導致帶寬用不滿也會導致性能上不去，所以，性能測試還需要根據實際情況有選擇的測試一下這兩咱場景。

（註：在路透，路透會用第二步得到的吞吐量乘以66.7%來做為系統的軟報警線，80%做為系統的硬報警線，而極限值僅僅用來扛突發的peak）

性能測試入門（一）：性能測試中的各項指標告訴我們什麽