某系統單點登錄性能測試診斷分析優化過程
原因說明
下面描述的是前段時間協助本地一家上市IT公司做產品技術選型時對他們的技術框架進行性能測試與優化過程記錄，因測試過程中涉及數據庫選型和各類問題的監控分析優化，篇幅比較大，本次主要是描述在同樣基礎軟硬件下、同樣應用工程包和框架、同樣數據量下，針對MYSQL環境下進行單點登錄壓力測試的結果過程記錄。
初始環境配置
測試內容
1、 用戶登錄，首頁查看，退出
2、 某業務交易新增、查詢、刪除、上傳文件
3、 業務審批流程創建、提交、審批、同意等工作流程；
問題診斷分析
LR端監控分析
在壓力測試中，首先壓力測試，登錄首頁、退出，10個用戶並發
應用資源使用監控分析
因為是使用wind2008系統服務，監控相對比較方面，通過任務管理器監控，發現應用服務器CPU使用不均衡，出現類似單線程死鎖現象，其中一個CPU線程使用率大於80%，而另外一個CPU線程使用率非常低，如下圖:
這時發現網絡帶寬使用率也非常高，10用戶並發網絡IO瓶頸每秒大於100M，如下圖：
通過與網管交流，服務器給予配置的網卡是1G，那說明是應用服務端發送數據給客戶端展現導致網絡帶寬使用偏高，最終導致前端120秒超時問題出現，因為是使用虛擬機環境，為了更好的證明是不是應用問題，也加以猜測懷疑是不是剛好有其他原因導致的，這時我停止壓力測試發現再沒壓測情況下網絡帶寬使用
說明是應用某方面問題引起如上問題，這時也看到操作系統可用物理內存一直持續降低，響應時間也越來越大，為了更準確的查看具體問題原因，查看tomcat應用日誌分析發現，應用日誌展示內存溢出現象java.lang.OutOfMemoryError: GC overhead limit exceeded，如下圖：
通過日誌細化分析，發現登錄首頁，會展現業務相關信息，而且需要全表掃描方式通過MYSQL服務撈取數據結果集，然後傳遞給應用端進行封裝展現給前端，最終出現表現現象是前端lr出現120秒超時，後臺應用CPU單線程死鎖、網絡傳輸帶寬使用率偏高，內存溢出現象，具體抓取分析的日誌如下：
java.lang.OutOfMemoryError: GC overhead limit exceeded
at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3669)
at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3609)
JVM分析
通過壓力測試過程發現內存溢出時，監控到的JVM使用如下圖：無法正常GC回收導致，內存溢出，也發現了JVM默認配置下有問題，如果配置合理JVM使用雖然會異常，但是還是可以強制GC回收，問題如下圖：
根源定位
因登錄首頁後需要刷新框架，其中最大問題是框架設計中對登錄首頁會對某一個業務交易的公告信息進行時時刷新展現數據，如果對應業務表數據量有多少，則公告信息就全部展現，如下業務交易圖：
而框架中，公告信息展現需要加載到getBulletinList控件下，以目前現有測試數據量，單用戶下該控件大需要展現的數據大小17M，導致10個用戶並發時網絡帶寬和java虛擬機出現異常，而且數據庫出現類似如下鎖表信息：
當然壓力測試過程中抓取其他鎖表語法，例如用戶登錄對應的SQL語法，也會導致響應時間超時：
優化方法
1、 通過建立索引方式
2、 修改JVM配置新增新生代大小和強制GC回收機制
3、 因為框架設計問題，公告欄展現只展現最近時間前5筆數據；如果需要看詳細信息點擊”更多”在觸發後臺業務交易，進行查看詳細信息；
優化後監控
通過優化後，100用戶單點登錄並發壓力測試，應用服務器資源使用率，如下圖，CPU使用均衡，均低於30%，網絡帶寬使用率低於20M，數據庫資源使用率也都低於指標範圍，
應用JVM回收情況如下：
數據庫服務器資源使用情況如下：
LR壓力測試結果如下：
結：
本次壓力測試技術選型中的性能測試，涉及交易功能包含，登錄退出、管理交易、流程交易，也對軟硬件、操作系統參數、應用參數、代碼、數據庫產品對比、網絡配置、瀏覽器選型等進行性能測試監控診斷分析優化進行對比，如下:
本篇文章成文倉促，從選型的角度看，建議針對各種滿足不同功能需求的技術框架進行選型，當面臨技術選型時，首先考慮的要對產品架構進行合理的驗證評估，例如性能測試，也要根據不同的場景進行驗證測試，最終選擇一款合適的框架；
某系統單點登錄性能測試診斷分析優化過程