微服務壓力測試
壓力測試考察當前軟硬件環境下系統所能承受的最大負荷並幫助找出系統瓶頸所在。壓測都
是為了系統在線上的處理能力和穩定性維持在一個標准范圍內，做到心中有數。
使用壓力測試，我們有希望找到很多種用其他測試方法更難發現的錯誤。有兩種錯誤類型是:
內存泄漏，並發與同步。
有效的壓力測試系統將應用以下這些關鍵條件:重復，並發，量級，隨機變化。
性能指標
- 響應時間（Response Time: RT）
響應時間指用戶從客戶端發起一個請求開始，到客戶端接收到從服務器端返回的響應結束，整個過程所耗費的時間。
-
HPS（Hits Per Second） ：每秒點擊次數，單位是次/秒。
-
TPS（Transaction per Second）：系統每秒處理交易數，單位是筆/秒。
-
QPS（Query per Second）：系統每秒處理查詢次數，單位是次/秒。
對於互聯網業務中，如果某些業務有且僅有一個請求連接，那么 TPS=QPS=HPS，一般情況下用 TPS 來衡量整個業務流程，用 QPS 來衡量接口查詢次數，用 HPS 來表示對服務器單擊請求。
- 無論 TPS、QPS、HPS,此指標是衡量系統處理能力非常重要的指標，越大越好，根據經驗，一般情況下：
金融行業：1000TPS~50000TPS，不包括互聯網化的活動
保險行業：100TPS~100000TPS，不包括互聯網化的活動
制造行業：10TPS~5000TPS
互聯網電子商務：10000TPS~1000000TPS
互聯網中型網站：1000TPS~50000TPS
互聯網小型網站：500TPS~10000TPS
-
最大響應時間（Max Response Time） 指用戶發出請求或者指令到系統做出反應（響應） 的最大時間。
-
最少響應時間（Mininum ResponseTime） 指用戶發出請求或者指令到系統做出反應（響應）的最少時間。
-
90%響應時間（90% Response Time） 是指所有用戶的響應時間進行排序，第 90%的響應時間。
-
從外部看，性能測試主要關注如下三個指標
吞吐量：每秒鍾系統能夠處理的請求數、任務數。
響應時間：服務處理一個請求或一個任務的耗時。
錯誤率：一批請求中結果出錯的請求所占比例。
JMeter
下載安裝
官網：Apache JMeter - Download Apache JMeter
下載對應的壓縮包，解壓運行 jmeter.bat 即可
JMeter 壓測示例
1.添加線程組
線程組參數詳解：
- 線程數：虛擬用戶數。一個虛擬用戶占用一個進程或線程。設置多少虛擬用戶數在這里也就是設置多少個線程數。
- Ramp-Up Period(in seconds)准備時長：設置的虛擬用戶數需要多長時間全部啟動。如果線程數為 10，准備時長為 2，那么需要 2 秒鍾啟動 10 個線程，也就是每秒鍾啟動 5 個線程。
- 循環次數：每個線程發送請求的次數。如果線程數為 10，循環次數為 100，那么每個線程發送 100 次請求。總請求數為 10*100=1000 。如果勾選了“永遠”，那么所有線程會 一直發送請求，一到選擇停止運行腳本。
- Delay Thread creation until needed：直到需要時延遲線程的創建。
- 調度器：設置線程組啟動的開始時間和結束時間(配置調度器時，需要勾選循環次數為永遠)
- 持續時間（秒）：測試持續時間，會覆蓋結束時間
- 啟動延遲（秒）：測試延遲啟動時間，會覆蓋啟動時間
- 啟動時間：測試啟動時間，啟動延遲會覆蓋它。當啟動時間已過，手動只需測試時當前 時間也會覆蓋它。
- 結束時間：測試結束時間，持續時間會覆蓋它。
2.添加http請求
訪問測試百度
3.添加監聽器
4.啟動壓測
結果分析
- 有錯誤率同開發確認，確定是否允許錯誤的發生或者錯誤率允許在多大的范圍內；
- Throughput 吞吐量每秒請求的數大於並發數，則可以慢慢的往上面增加；若在壓測的機器性能很好的情況下，出現吞吐量小於並發數，說明並發數不能再增加了，可以慢慢的往下減，找到最佳的並發數；
- 壓測結束，登陸相應的 web 服務器查看 CPU 等性能指標，進行數據的分析;
- 最大的 tps，不斷的增加並發數，加到 tps 達到一定值開始出現下降，那么那個值就是最大的 tps。
- 最大的並發數：最大的並發數和最大的 tps 是不同的概率，一般不斷增加並發數，達到一個值后，服務器出現請求超時，則可認為該值為最大的並發數。
- 壓測過程出現性能瓶頸，若壓力機任務管理器查看到的 cpu、網絡和 cpu 都正常，未達到 90%以上，則可以說明服務器有問題，壓力機沒有問題。
- 影響性能考慮點包括： 數據庫、應用程序、中間件（tomact、Nginx）、網絡和操作系統等方面
- 首先考慮自己的應用屬於 CPU 密集型還是 IO 密集型
JMeter Address Already in use 錯誤解決
windows 本身提供的端口訪問機制的問題。
Windows 提供給 TCP/IP 鏈接的端口為 1024-5000，並且要四分鍾來循環回收他們。就導致我們在短時間內跑大量的請求時將端口占滿了。
1.cmd 中，用 regedit 命令打開注冊表
2.在 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters 下，
- 右擊 parameters，添加一個新的 DWORD，名字為 MaxUserPort
- 然后雙擊 MaxUserPort，輸入數值數據為 65534，基數選擇十進制（如果是分布式運
行的話，控制機器和負載機器都需要這樣操作哦）
- 修改配置完畢之后記得重啟機器才會生效
TCPTimedWaitDelay：30
中間件對性能的影響
網站發送請求的時候，經過nginx中間件，然后轉發到網關，網關再轉交給后台服務器集群，商品服務將數據處理完畢再裝交給網關，網關發送給nginx，nginx再返回給我們。
在真正功能執行前還經過了兩個中間件：nginx、Gateway，為了探究中間件對我們的性能有沒有影響以及影響有多少，於是對這些進行壓測。
壓測內容
Nginx
訪問:linux虛擬機的nginx地址：192.168.195.100:80
網關
訪問:網關192.168.195.88:88
簡單服務
訪問：http://localhost:10000/hello
Nginx+網關
開啟網關訪問路徑
全鏈路：簡單服務+Nginx+網關
訪問：gulimall.com:80/hello
首頁一級菜單渲染
訪問：localhost:10000/
三級分類數據獲取
localhost:10000/index/catalog.json
首頁全量數據獲取
訪問：localhost:10000/ 並開啟加載靜態資源
優化業務：
Db（MySQL 優化）
模板的渲染速度（緩存）
靜態資源
Nginx動靜分離
每次訪問都加載靜態資源很浪費系統資源，需要很多的線程去處理這些資源，為了加快系統訪問速度，把靜態資源配置在nginx，不需要經過網關。
-
首先，把商品服務中靜態文件夾 index 放到 nginx 下 /mydata/nginx/html/static目錄；
-
給模板中所有靜態資源的請求路徑前都加上 /static；
-
修改 Nginx 配置文件 /mydata/nginx/conf/conf.d/gulimall.conf
# /static/ 下所有的請求都/usr/share/nginx/html下尋找資源
location /static/ {
root /usr/share/nginx/html;
}
顯示成功