效能測試

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

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

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

效能指標

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等級分類，可以參考下

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

如何嚴謹地做效能測試

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

一般來說，效能測試要統一考慮這麼幾個因素：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）