可用性測試效能指标?可能很多新手QA、RD同學，對服務端壓測一直沒有系統的認知，印象停留在使用壓測工具如Jmeter對單接口發壓，調整線程數和循環數來制造不同壓力，最後計算一下TPS和成功率等就完事了？網上雖然有不少壓測相關的文章，但多數是壓測工具的入門級使用，有的是壓測流程和指标的簡單解釋，或者就是幾個大廠牛逼的全鍊路壓測能力和壓測平台的介紹這些文章要不缺少系統性闡述，要不過于抽象不好理解，對沒怎麼接觸過壓測的同學看起來還是不太理解，本文就重點從壓測指标如何評估這個角度出發，現在小編就來說說關于可用性測試效能指标?下面内容希望能幫助到你，我們來一起看看吧!

可用性測試效能指标

可能很多新手QA、RD同學，對服務端壓測一直沒有系統的認知，印象停留在使用壓測工具如Jmeter對單接口發壓，調整線程數和循環數來制造不同壓力，最後計算一下TPS和成功率等就完事了？網上雖然有不少壓測相關的文章，但多數是壓測工具的入門級使用，有的是壓測流程和指标的簡單解釋，或者就是幾個大廠牛逼的全鍊路壓測能力和壓測平台的介紹。這些文章要不缺少系統性闡述，要不過于抽象不好理解，對沒怎麼接觸過壓測的同學看起來還是不太理解，本文就重點從壓測指标如何評估這個角度出發。

壓測流程

完整的壓測流程一般包含下面幾個步驟：

1、壓測目标的制定

2、壓測鍊路的梳理

3、壓測環境的準備

4、壓測數據的構造

5、發壓測試

6、瓶頸定位及容量微調

7、壓測總結和報告

壓測指标

列舉一些常用指标，并不一定都需要關注，根據業務考慮指标的細化粒度。

QPS：Query Per Second，每秒處理的請求個數

TPS：TransactIOns Per Second，每秒處理的事務數，TPS <= QPS

RT：Response Time，響應時間，等價于Latency

RT分平均延時，Pct延時（Percentile分位數）。平均值不能反映服務真實響應延時，實際壓測中一般參考Pct90，Pct99等指标

CPU使用率：出于節點宕機後負載均衡的考慮，一般 CPU使用率 < 75% 比較合适

内存使用率：内存占用情況，一般觀察内存是否有尖刺或洩露

Load指标：CPU的負載，不是指CPU的使用率，而是在一段時間内CPU正在處理以及等待CPU處理的進程數之和的統計信息，表示CPU的負載情況，一般情況下 Load < CPU的核數*2，更多參考鍊接1和鍊接2

緩存命中率：多少流量能命中緩存層（redis、memcached等）

數據庫耗時：數據庫就是業務的生命，很多時候業務崩掉是因為數據庫挂了

網絡帶寬：帶寬是否瓶頸

接口響應錯誤率 or 錯誤日志量

這裡要說明一下QPS和TPS的區别：

QPS一般是指一台服務器每秒能夠響應的查詢次數，或者抽象理解成每秒能應對多少網絡流量

TPS是指一個完整事務，一個事務可能包含一系列的請求過程。舉個，訪問一個網頁，這是一個TPS，但是訪問一個網頁可能會對多個服務器發起多次請求，包括文本、js、圖片等，這些請求會當做多次QPS計算在内，因為它們都是流量性能測試中，平均值的作用是十分有限的，平均值代表前後各有50%的量，對于一個敏感的性能指标，我們取平均值到底意味着什麼？是讓50%的用戶對響應時間happy，但是50%的用戶感知到響應延遲？還是說50%的時間系統能保證穩定，而50%的時間系統則是一個不可控狀态？

平均響應時間這種指标，隻有在你每次請求的響應時間都是幾乎一樣的前提下才會有一樣。再來個例子，人均财富這個概念有多沙雕相信大家也明白，19年有個很搞笑的新聞——騰訊員工平均月薪七萬，明白平均值多不靠譜了吧。下圖是現實世界中一個系統的響應時間柱狀圖，RT在前20%的請求數較少，但是因為耗時特别短（拉高了均值可能是命中緩存，也可能是請求的快速失敗），而大多數RT是在均值之下，那才是系統的實際性能情況。

均值并不能反映實際情況，所以說，我們不應看最好的結果，相反地，應該控制最壞的結果，用戶用得爽他不保證會傳播好口碑，但是用戶用到生氣他保證變為鍵盤俠肆意大罵，這也是為什麼平均值無法帶來足夠的參考，因為happy的結果蒙蔽了我們的雙眼，平均值在壓測中丢失太多信息量。

總結一下，較為科學的評估方法應該将指标-成功率-流量三者挂鈎在一起的，比如：99%的響應在500毫秒内返回，其中成功率為99.99%。

根據這個方針，可以得到一些測試思路：

1、在響應時間的限制下，系統最高的吞吐量（這裡不對吞吐量做嚴格定義，當成是QPS或TPS即可）

2、在成功率100%的前提下，不考慮響應時間長短，系統能承受的吞吐量

3、容忍一定的失敗率和慢響應，系統最高能承受的吞吐量（95%成功率，前95%的請求響應時間為xx毫秒時的最大QPS）

4、在上面的場景下還要考慮時間和資源，比如最高吞吐量持續10分鐘和持續1小時是不一樣的，不同的時間持續長度下，機器資源（cpu、内存、負載、句柄、線程數、IO、帶寬）的占用是否合理

目标預估

壓測開展前是需要有目标的，也就是有期望的性能情況，希望接口或系統能達到的性能預期，沒有目的的壓測是浪費人力，下面給出幾種目标預估的方法。

曆史監控數據

已經上線并且有曆史監控數據的接口，可以查看曆史數據，找出峰值QPS和PCT99。 若接口A已經上線并且做了監控，在經過某次大活動或者上線時間足夠長後，存量監控數據就可以使用了。

類比

新接口或者線上未監控的接口，不存在曆史數據，但存在類似功能接口的曆史監控數據，可以通過類比得出壓測的目标。 假設上一年淘寶雙十一下訂單接口QPS=x，RT=y，這一年天貓平台整起來了，雙十一活動與上年淘寶雙十一活動場景類似，也沿用QPS=x，RT=y的目标（例子不嚴謹，理解即可）。

估算

新接口或者線上未監控的接口，不存在曆史數據，且不存在類似功能接口的數據可供參數考，此時需要估算峰值，常用方法有8/2原則——一天内80%的請求會在20%的時間内到達。

top QPS = (總PV * 0.8) / (60 * 60 * 24 * 0.2)

RT如無特殊要求，一般采用默認值：

單服務單表類，RT<100ms

較複雜接口，RT<300ms

大數據量或調用鍊較長的接口，RT<1s

-1：電商秒殺活動，預估同時有1000w人參與，簡單起見假設總QPS是1000w。由于前端不同的秒殺倒計時形式使得請求有2s的打散，再加上nginx等webserver做了20%幾率拒絕請求的策略，所以下單接口總QPS = 1000w / 2 * (1 - 0.2) = 400w/s，最終壓測目标為400w/s的QPS。

-2：電商全天低價搶購活動，屠龍寶刀，點擊就送，一刀99級，emmmmm跑題了。根據8/2原則，預估在午休（12-1）和晚上下班後（7-10）共4h是流量高峰，估算接口峰值QPS = 活動全天接口PV / (4*3600s)。

其他

除了前面說到的情況，肯定還有一些我們無法下手的三無接口，無參考、無預估、無曆史數據，這時候隻能一點一點來，慢慢把壓力提上去的同時收集數據，最終得出接口的最優處理能力。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!