jmeter性能測試總結

1、性能測試問題記錄：

Ⅰ、秒殺的失敗率了在96.45%，緣由 Query對於 活動的秒殺採用的是0.5秒，刷新緩存的策略在活動中優惠券被秒殺一空

下架前，短暫的時間內仍可以查詢到 這個活動架構中採用了CQRS模式只保證了最終結果一致性，並不能保證明時一致性。

Ⅱ、日誌級別爲Info，致使CPU很大一部分的是用來處理日誌相關的功能，

Ⅲ、異步輸出日誌能比同步輸出的方式下，提高了接近100%的吞吐量

Ⅳ、代碼中存在大量數據庫鏈接使用未關閉的狀況，致使後續事務沒法獲取數據庫鏈接

Ⅴ、logstach配置錯誤，致使redis數據沒法及時導出，2G存儲量很快被佔滿報錯

Ⅵ、MQ隊列使用錯誤，爲每次事務單獨創建了隊列，且這些隊列沒法自動清除

Ⅶ、網關配置有誤，致使限流發生；對接ERP方式代碼有誤；數據庫配置錯誤，致使性能緩慢

Ⅷ、數據庫出現死鎖

Ⅸ、QPT(請求數)增長↑，TPS（吞吐量）沒有上去，是由於當時服務器能處理就這麼多

Ⅹ、服務器的配置確實偏弱，1核8G，須要同時跑網關、外賣等多服務，且此時並未分多節點部署

 

2、jmeter使用技巧點記錄：

一、因爲變量 沒法在不一樣的線程組中共享和傳遞，這時候 Beanshell postprocess組件就排上用場了，它的做用將當前線程組中目標變量轉換爲全局變量

二、jmeter集合點：經過添加定時器來完成，只能做用於JVM中 

三、硬件服務器不足時，可採用Jmeter的分佈式集羣，遠程啓動測試

四、性能測試數據，除了.cvs、txt等通常模擬數據外，還可使用 脫敏後的線上數據

 

3、性能測試經驗小結：

一、性能測試通常都是須要進行多輪測試，所以，性能調優是一個循環過程

二、代碼質量過關，性能測試就只是走個過場

三、性能測試可能找出開發編碼不合理，同時也能 幫助運維找出更合適的系統應用部署方案

四、在性能測試過程當中，系統架構圖做用就很明顯了，在日誌報錯信息不明確狀況下，能夠查看每部分的監控信息，

查出報錯緣由，若是沒有架構圖，則只能東一榔錘西一棒頭，效率很低。

 五、log4j2的吞吐量相對於log4j1而言大幅提升了約40%，內存使用量也更少了。所以，推薦使用性能更佳的log4j2替換掉陳舊的log4j1。

4、性能需求指標項和指標值二八原則：

eg:，每日派件量1000W，按照2：8原則推算：

　　（1000W*80%）、（8*3600*20%）=1388.8，取整爲1389筆/每秒

　　每一年按照業務量增加50計算，一年後系統處理能力指標約等於：1389*(1+50%)=2083.3，取整爲2084筆/每秒

　　按照穩定性交易量推導：取系統處理能力的80%計算：

　　80%*2084*8*3600=36011520≈3601W筆/天

 

 

5、性能工具引入：

一、Jmeter：用於進行負載和壓力測試

二、jProfiler：用於進行性能測試分析

三、nmon：用於監控系統負載

四、zabbix：用於監控服務器硬件信息

五、pinpiont:分佈式系統監控工具

六、Jmeter的PerfMon插件

七、固然也能夠用雲智慧的監控寶和透視寶協同工做，監控寶能夠監控網站／網頁性能／Ping/DNS/FTP/UDP/TCP/SMTP等IT基礎設施的性能指標，透視寶能夠發現主機資源、Web應用、瀏覽器、APP等應用的性能瓶頸，

監控寶監控頁面：

6、性能實施流程：

一、性能測試流程分爲五個階段，分別是【需求調研階段】→【測試準備階段】→【測試執行階段】→【測試報告階段】→【測試總結階段】。

二、性能需求提供者：通常爲產品人員/業務方/研發人員

需求調研：需求調研工做由性能測試實施人員牽頭負責，產品經理、開發工程師、運維工程師配合完成；

需求調研的主要內容爲：系統線上環境的性能需求，例如性能需求、可靠性需求、可維護性需求等；