壓力測試
壓力測試不同于功能測試，其目的是為了測試出系統(tǒng)在高并發(fā)，高數(shù)據(jù)量的情況下可能會出現(xiàn)的問題（內(nèi)存泄露、并發(fā)、同步）
一種典型的內(nèi)存泄漏就是對象在創(chuàng)建之后由很多用戶進行調(diào)用，導致對象被不斷新建但復用率很低，導致內(nèi)存不足（內(nèi)存泄露的典型問題）
有效的壓力測試應(yīng)用的關(guān)鍵條件：重復、并發(fā)、量級、隨機變化
性能指標
-
響應(yīng)時間：客戶端從發(fā)起一個請求開始，到接收到服務(wù)器的響應(yīng)為止，整個過程所耗費的時間
-
TPS：系統(tǒng)每秒能夠處理的事務(wù)數(shù)（Java中的事務(wù)，暨一系列不可中斷的操作）
-
QPS：系統(tǒng)每秒處理的查詢次數(shù)（次/秒）（一般指接口的查詢次數(shù)）
TPS、QPS、HPS都是衡量系統(tǒng)處理能力的非常重要的指標，越大越好，
- 金融行業(yè)：1000 - 50000 TPS
- 保險行業(yè)：100 - 100000 TPS 可能涉及到極其復雜的業(yè)務(wù)場景，這種情況下允許TPS降低
- 制造行業(yè)：10 - 5000 TPS 使用并發(fā)量低，對高并發(fā)場景沒有很高的要求
- 互聯(lián)網(wǎng)電子商務(wù)：10000 - 1000000 TPS
- 互聯(lián)網(wǎng)中型網(wǎng)站：1000 - 50000 TPS
- 互聯(lián)網(wǎng)小型網(wǎng)站：500 - 10000 TPS
-
最大響應(yīng)時間：用戶發(fā)出請求到收到響應(yīng)的最長時間
-
最少響應(yīng)時間：用戶發(fā)出請求到收到響應(yīng)的最短時間
-
90%響應(yīng)時間：所有用戶的響應(yīng)時間進行排序，第90%的響應(yīng)時間
-
此外，我們要看重的指標主要有：吞吐量（每秒鐘系統(tǒng)可以處理的請求數(shù)、任務(wù)數(shù)）、響應(yīng)時間：（服務(wù)處理一個請求或一個任務(wù)的耗時）、錯誤率：（一批請求中結(jié)果出錯的請求所占的比例）
JMeter
壓力測試工具有很多選擇，這里我們選擇JMeter進行壓力測試，一般選擇添加線程組、線程組下的HTTP請求、查看結(jié)果樹、匯總報告、聚合報告、匯總圖等信息用來檢查結(jié)果，結(jié)果可以查看吞吐量、90%百分位、中位數(shù)等信息來判斷系統(tǒng)性能
Windows下JMeter Address In Use錯誤的解決
由于我們使用JMeter時，每一次測試請求都需要占用一個windows端口，windows允許的對外端口是1024 - 5000 ，而Windows所需要的回收時間是4分鐘，故我們在短時間進行測試時，會發(fā)生端口不夠用的問題
在regedit注冊表信息中添加：
計算機\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
下新建DWORD值：MaxUserPort：65534、TCPTimedWaitDelay：30
使其端口最大允許65534、TCP回收時間為30S
性能優(yōu)化思路
首先，我們要知道影響性能的因素，主要包括：數(shù)據(jù)庫、應(yīng)用程序、中間件、網(wǎng)絡(luò)、操作系統(tǒng)等因素，再具體在其中進行對應(yīng)的優(yōu)化
其次，我們要知道我們的應(yīng)用程序?qū)儆?strong>CPU密集型 還是 IO密集型，系統(tǒng)常見的是計算、排序、數(shù)據(jù)處理等操作一般是CPU密集型應(yīng)用程序、常見的是進行數(shù)據(jù)讀取，發(fā)送，存儲的一般屬于IO密集型應(yīng)用程序，同時，我們也可以通過其實際上的運行情況進行判斷我們目前更需要哪方面的優(yōu)化（看CPU占用和IO占用情況）
JVM簡述：
我們在存放一個新的對象時，會優(yōu)先檢查其是否能被存儲在新生代的Eden區(qū)，若放不下，則會進行YoungGC，對新生代進行檢測并清除，再檢查是否能放下，若還放不下，則直接向老年區(qū)存儲，若還是放不下，則進行Full GC，若還是放不下則會拋出OOM異常
同時，我們會盡量將Eden區(qū)的數(shù)據(jù)放到幸存者區(qū)，以保證我們在新增對象的時候可以直接存放，不進行GC，另外Full GC的速度是Y GC速度的10倍左右，高頻的FullGC會導致系統(tǒng)性能極差
使用jvisualvm監(jiān)控性能指標
我們常用的監(jiān)控系統(tǒng)JVM性能指標的工具有jconsole、以及他的升級版jvisualvm，這里我們使用升級版的工具jvisualvm進行性能監(jiān)控：
注意，高版本JDK已經(jīng)不再自動集成jvisualvm，需要我們自己安裝
jvisualvm的作用：監(jiān)控內(nèi)存泄漏、跟蹤垃圾回收、執(zhí)行時內(nèi)存、CPU分析、線程分析…
運行：正在運行的線程
休眠：sleep中的線程
等待：wait的線程
駐留：線程池中的空閑線程
監(jiān)視：阻塞的線程（正在等待鎖的線程）
安裝Visual GC
tools -> Plugins 在settings中打開網(wǎng)址（io結(jié)尾）在download中選擇左邊的Visual GC下載，不要被網(wǎng)上的教程從右邊下載欺騙，下載安裝之后我們就可以查看對應(yīng)的Java線程的GC信息
實際使用壓力測試進行簡單優(yōu)化
在Linux中，我們可以使用docker status來對Linux中的線程進行監(jiān)控，從而做出進一步的判斷，創(chuàng)建單測，進行一定的測試：
| 壓測內(nèi)容 | 壓測線程數(shù) | 吞吐量/s | 90%響應(yīng)時間 | 99%響應(yīng)時間 |
|---|---|---|---|---|
| Nginx | 50 | 9755 | 8 | 22 |
| Gateway | 50 | 34727 | 2 | 5 |
| 簡單接口 | 50 | 24266 | 3 | 6 |
| Gateway + 簡單接口 | 50 | 5500 | 17 | 45 |
| Nginx + Gateway + 簡單接口 | 50 | 2100 | 30 | 53 |
| 首頁接口（單獨） | 50 | 230 | 341 | 543 |
| 三級分類接口（嵌套循環(huán)查詢） | 50 | 1（2，加索引后）（8，業(yè)務(wù)優(yōu)化后） | 34300 | 38400 |
| 首頁全量數(shù)據(jù)（包括靜態(tài)資源渲染）（無Thymeleaf緩存） | 50 | 68 | 947 | 1529 |
| 首頁全量數(shù)據(jù)（包括靜態(tài)資源渲染）（有Thymeleaf緩存） | 50 | 72 | 819 | 1007 |
| 首頁全量數(shù)據(jù)（包括靜態(tài)資源渲染）（有Thymeleaf緩存、數(shù)據(jù)庫加索引、關(guān)日志） | 50 | 100 | 731 | 1232 |
| 首頁全量數(shù)據(jù)（不包括靜態(tài)資源渲染）（有Thymeleaf緩存、數(shù)據(jù)庫加索引、關(guān)日志） | 50 | 310 | 286 | 423 |
| 首頁全量數(shù)據(jù)（包括靜態(tài)資源渲染）（動靜分離） | 50 | 20 | 3228 | 4778 |
| 首頁全量數(shù)據(jù)（包括靜態(tài)資源渲染）（動靜分離 + 增加內(nèi)存，增加新生代使用內(nèi)存（-Xmx1024m -Xms1024m -Xmn512m）（最大內(nèi)存，初始內(nèi)存，新生代內(nèi)存）） | 50 | 25 | ||
我們可以直觀的看出來：單獨Gateway和單獨簡單接口都有較高的吞吐量，而兩者結(jié)合就會使性能大幅下降，故：中間件越多，系統(tǒng)性能損耗越大（主要損失在網(wǎng)絡(luò)IO上）
注意，此處的壓力測試是通過本機測本機的結(jié)果，這種結(jié)果不太具有參考價值，因為壓測的線程會和實際運行的線程發(fā)生競爭，使得結(jié)果偏差
在單獨的首頁中：主要的性能影響因素是DB操作以及Thymeleaf渲染文章來源：http://www.zghlxwxcb.cn/news/detail-770308.html
在三級分類接口中：主要的性能影響因素就是死亡一般的嵌套查詢操作以及DB操作文章來源地址http://www.zghlxwxcb.cn/news/detail-770308.html
到了這里，關(guān)于【性能優(yōu)化】一、使用JMeter進行壓力測試并進行簡單調(diào)優(yōu)的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
