背景

小A：小B，最近調你的接口老是超時呀，8秒都還沒返回結果，是不是有性能問題呀！
小B ：我看看~~

類似這樣的對話，在現實中是時有發生的，不是特別嚴重的話，往往大家也不會去重視這個事。

尤其是在一些測試資源并不完備的，開發人員對性能測試沒有接觸過的一些公司，遇到這些會顯得更加力不從心。

本著對自己寫出來的東西負責，上線之前，我們都應該對自己的接口進行一個簡單的壓力測試。

其實做這一步也是為了讓我們心里有個度，有個底，不至于說連能承受多少量都不知道。如果什么都不知道，那很容易陷入一個無底深淵，這是一件很可怕的事情。

老黃平時用的比較多的是Apache Bench，當然，jmeter、wrk和vegeta也都是非常不錯的。

說說用這個的原因吧，免安裝，綠色版，開箱(解壓)即用，說白了，老黃其實就是懶鬼~~

jmeter要裝jdk，懶得弄。

wrk/wrk2 要自己編譯，mac上面可以直接安裝，但是我的mac配置不高，不折騰。

vegeta用起來感覺不是很順手，后面再慢慢挖掘。

Apache Bench 介紹

Apache Bench 是Apache服務器自帶的一個web壓力測試工具，簡稱ab。

ab是一個命令行工具，對發起負載的本機要求很低，根據ab命令可以創建很多的并發訪問線程，模擬多個訪問者同時對某一URL地址進行訪問，因此可以用來測試目標服務器的負載壓力。總的來說ab工具小巧簡單，上手學習較快，可以提供需要的基本性能指標，但是沒有圖形化結果，不能監控。

ab進行的測試的本質是基于HTTP協議，可以理解為對web服務器軟件的黑盒性能測試，獲得的一切數據和計算結果，都是可以通過HTTP來解釋的。

Apache Bench 簡單使用

下面的示例都是在CentOS上面的。

通過下面的命令安裝，

yum -y install httpd-tools

裝好之后，運行一下ab -V就可以看到版本信息。

ab -VThis is ApacheBench, Version 2.3 <$Revision: 1430300 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/

運行一下ab -h就可以看到幫助信息。

幫助信息有很多，也比較詳細，老黃把一些常用的參數都添加了注釋，方便大家查看。

其中最常用的兩個參數是 -c 和 -n，當然如果是POST/PUT請求的話，還離不開 -T 和 -p。

說了不少廢話，來看看怎么使用才是重點。

下面準備了兩個簡單的接口來進行演示

[ApiController] [Route("test")] public class TestController : ControllerBase {[HttpGet]public string Get() => "GET";[HttpPost]public string Post([FromBody]string value) => value; }

這個接口是跑在docker里面的(一臺2c4g的活動云服務器)，下面的圖可以看到具體的信息，還有兩個接口的訪問詳情。

先來壓一下GET請求的接口， 200并發，5000個請求。

ab -c 200 -n 5000 localhost:9000/test

POST請求有點不一樣，要先準備一下body的參數，這里在/tmp目錄創建了一個post.json文件，里面就一個字符串。

cat /tmp/post.json "Post"

在壓測命令里面，指定Content-Type為application/json， 參數的數據文件路徑是/tmp/post.json

同樣也是200并發，5000個請求。

ab -c 200 -n 5000 -T "application/json" -p /tmp/post.json localhost:9000/test

到這里，大家對怎么壓測，應該都不會太陌生了，比較陌生的應該是壓測的結果要怎么看。

下面拿其中一個結果示例來說明各項指標的含義：

Server Software: Kestrel # 服務器軟件名稱 Server Hostname: localhost # 服務器主機名 Server Port: 9000 # 服務器端口Document Path: /test # 測試的URL路徑 Document Length: 3 bytes # 文檔大小Concurrency Level: 200 # 并發數 Time taken for tests: 2.386 seconds # 消耗的總時間 Complete requests: 5000 # 總次數 Failed requests: 0 # 失敗的請求數 Write errors: 0 # 網絡連接寫入錯誤數 Total transferred: 680000 bytes # 傳輸的總數據量 HTML transferred: 15000 bytes # HTML文檔的總數據量 Requests per second: 2095.43 [#/sec] (mean) # (平均每秒的請求數) 這個是非常重要的參數數值，服務器的吞吐量 Time per request: 95.446 [ms] (mean) # (所有并發用戶都請求一次的平均時間) Time per request: 0.477 [ms] (mean, across all concurrent requests) # (單個用戶請求一次的平均時間) Transfer rate: 278.30 [Kbytes/sec] received # 每秒獲取的數據長度 (傳輸速率，單位：KB/s)# 網絡上消耗的時間的分解 Connection Times (ms)min mean[+/-sd] median max Connect: 0 3 3.7 2 20 Processing: 12 68 120.0 53 1057 Waiting: 1 67 120.1 52 1050 Total: 15 71 119.8 55 1058# 整個場景中所有請求的響應情況 Percentage of the requests served within a certain time (ms)50% 5566% 6375% 6880% 7190% 7795% 8898% 10599% 1012100% 1058 (longest request)

這么多的指標，我們可以重點關注下面幾個

Requests per second

Failed requests

90%，95%和98%的響應時間

第一個是吞吐量，這個上不去，其實是挺尷尬的。

第二個是失敗的請求數，這個數要盡可能的低，最好是0，沒有失敗的。設想一下，100個請求，80個都是失敗的，這個結果還能有意義不。

第三個是響應時間，這個可以看到大部分請求的速度如何。

進行壓測時的一些小建議：

• 壓測盡可能讓并發數從低往高慢慢遞增，避免一開始就設的太大，一個比較好的參考依據是現在階段線上環境的并發數

• 壓測的持續時間可以持續久一點，這樣可以看到更多可能出現的情況，可以考慮5分鐘，8分鐘，15分鐘等

• 有條件的，壓測和被壓測的機器要獨立，因為壓測的時候也會有資源占用，可能會影響被壓測的接口

• 不要只看壓測的結果數據，還要留意被壓測機的cpu，內存等指標在壓測時是否正常

• 內網壓測的效果達到預期后，再考慮外網的，網絡因素，可控性不強

分布式壓測和全鏈路壓測，暫時不用想了，留給更專業的人去做吧~~

總結

以上是生活随笔為你收集整理的后端开发都应该了解点接口的压力测试(Apache Bench版)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。