大家都知道性能測試中,性能指標包括系統吞吐量，并發處理能力，系統穩定性，響應延遲等。性能測試就是為了如果發現有不滿足要求的地方，需要定位出問題所在，并給出解決方案。今天小編來給大家說說接口壓力測試的相關內容。

為什么要做接口壓力測試?

1.清楚自己所提供的接口性能是多少;

2.判斷出系統可能存在的問題（代碼，DB，cache，系統配置,容量等），提前解決;

3.為設置接口的限流/熔斷做參考;

接口壓力測試的局限性

接口壓力測試只注重單業務的接口性能，進行壓測的時候，只關注個別接口的性能。

接口大部分時間是在線下進行，可能線上線下機器配置不一樣，而且線上同時在進行著各種不同的業務。

因此在線下進行接口壓力測試的結果，只能作為線上配置的一個參考值。

如何做接口壓力測試?

通常使用 Jmeter ，loadRunner，PerformanceRunner 等進行壓力測試。

如何確定并發數：

可以通過嘗試的方式。第一次壓測的時候，可以設置自己預期接口需要達到的并發數，進行壓力測試。然后通過二分法進行調整。

舉例：如果期望的并發數是512 ，第一次壓測并發數設置為512 ，如果系統沒有壓力，第二次并發就嘗試設置為1024。如果系統有壓力，下次就設置為256。通過逐漸嘗試的方式，找出當前接口的并發閾值。

如何確定總請求次數：

有時候單純的通過并發數并不能完全發現系統的壓力狀況，因為并發數只能測出系統的處理能力。

但是有時隨著長時間的調用，系統可能會出現其他問題。比如：隨著數據量的增多，存儲磁盤滿了、內存緩存用光，緩存服務使用磁盤緩存而拖慢系統等情況。

為了避免這種情況，可以嘗試用現有線上業務每天產生的數量乘以一定的天數（天數的大小視業務的具體情況而定，推薦180天以上），作為接口壓力測試的總請求次數。

接口壓力測試數據的選取：

通常隨機選擇數據。但是要注意重復進行壓力測試對性能的影響。

比如：

第一次壓測的 Id 是從2500W 到2600W 之間選擇的，下次用同樣的 Id 范圍做壓測的時候，如果接口實現中有緩存，則會很大程度影響壓力測試的結果，對壓力測試的解讀時候，要考慮到這個因素。

另外，使用不存在的 Id 去進行壓測，結果并沒有太大意義。

七、壓力測試報告應該包含哪些結果

接口壓力測試結果

服務器壓力

每次接口壓力測試時，接口所在服務的服務器 cpu/jvm 使用率歷史記錄，jvm堆大小，響應時長圖 （借助 pinpoint 查看），cpu load 值（top 命令），gc 信息等。

對于接口壓力測試結果：

關注 響應時間是否符合要求，響應時間（前99%） 是不是在可允許的范圍內。最大值是多少，是否可以容忍。 通常來說，錯誤百分比應該為0。

對于服務器壓力：

看 cpu 使用率是否在可接受范圍內，jvm 堆大小是否變化頻繁，是否有 fullGC。Young GC 耗時，CPU load值是否在可接受范圍內。 響應時長圖是否平滑（如果有毛刺現象，需要找出原因）。

如何根據測試結果定位性能問題

1.響應時間不符合要求：通過 pinpoint 觀察調用鏈，找出耗時比較長的步驟，進行優化；

2.并發數達不到要求，可以從以下幾個方面進行考慮：

a 是否發生系統依賴資源爭用（比如：數據庫連接，業務處理線程數等）

b 業務流程/代碼性能是否可以優化

c 在運行的過程中是否頻繁 GC

3. CPU 使用率過高：

a 在運行的過程中是否頻繁 GC

b是否發生過多的線程切換

c 程序中是否有比較耗 cpu 的代碼

修復性能問題

除了只可能在極端壓力測試情況下會發生的性能問題，并且修復代價過大的問題可以不進行修復修復性能問題

除了只可能在極端壓力測試情況下會發生的性能問題，并且修復代價過大的問題可以不進行修復，但是要在壓力測試報告中體現出來此問題，以及解決方案），其他問題都必須進行修復。

如果沒有專門的接口壓力測試環境，記得做完接口壓力測試之后，將測試數據清除(緩存，數據庫，消息中間件中未消費完畢的消息 等)。

推薦閱讀：

全鏈路性能需求分析的要點是什么？和傳統線下性能測試有什么區別

軟件測試中服務器穩定性測試方法有哪些?

有哪些SQL性能測試工具？SQL性能測試工具的主要特點

性能測試和并發壓力的關系 性能測試中怎么設置并發數？

什么是WebSocket？有哪些支持WebSocket協議的壓力測試工具？

性能壓測概念及性能壓測工具對比選型

企業為什么需要做全鏈路壓測？全鏈路壓測能解決什么問題？

接口壓力測試怎么才能做好？接口壓力測試要點

cs項目怎么做性能測試？cs性能測試跟bs有什么區別？