前段時間客戶方一個系統上線后出現性能問題，就是查詢報表的時候出現宕機現象，應項目組要求過去幫忙測試優化問題。
該項目的架構相對比較復雜，登錄后要先進行認證服務器認證用戶然后登錄到應用系統A,在跳轉到應用服務器B進行業務操作，如果有涉及到查詢歷史數據等需要使用到查詢報表的，就要再次跳轉到cognos服務器，然后從數據庫中撈取數據，因為項目人員只是說登錄很慢，而且應用系統也很慢，有時會內存溢出，經常重啟，但是沒說明是哪里出問題，所以對問題的定位分析確實很麻煩。
于是只能逐層剝離測試分析方式來對各層次服務器進行問題定位分析解決。
1、先測試挖掘分析web服務器問題，通過簡單的測試系統登錄退出，定位解決了apache配置問題。
2、認證服務慢的問題是存在，但是是另外一個系統問題，所以不做任何優化修改。
3、本項目的應用服務器問題診斷分析，通過測試一些交易類型的不跟報表打交道的業務功能點發現weblogic的JDBC、JVM等配置方面的問題，但是這時只能說發現問題，雖然JDBC調整大小可以解決連接數問題但是JVM設置問題，還需要考慮業務模型測試模型配比進行調整，因為報表展現的數據需要加載到應用JVM然后在展現出來，所以這方面的調整只能綜合場景測試，才能進行分析優化調整。
服務配置測試診斷分析，通過測試查詢報表數據，進行測試應用、報表展現分析問題，cognos的相關參數配置，如cognos Sort buffer size、CQEConfig.xml修改、最大進程數調整等進行調整然后針對JVM進行調整。
4、數據庫問題，在測試過程沒有發現SQL寫法問題，引發數據性能問題都是數據庫緩存配置問題引發的，報表服務器的數據庫是可以適當把緩存參數設置大一些，提高性能，如數據緩存、高數區緩存等配置，提高數據命中率等問題。
5、JVM的配置差異性：雖然都是使用同種類型的linux操作系統和硬件配置，同樣使用jrockit JDK，但是面對的處理的技術和業務邏輯的差異性，導致對JVM配置也相應有一定的差異，如應用服務器是面對不只是報表數據展現也有管理類交易的而cognos服務器是針對數據的展現，如果歷史數據的查詢展現等為主，所以應用服務器和報表服務器對于的JVM配置方式不能設置一樣，如 應用服務器JVM配置如 -Xms1024m -Xmx1024m -Xns:256m -Xgc:gencon
而報表服務器配置-Xms1024m -Xmx1024m -Xgcprio:throughput –XnoOpt -Xverify:none，在測試過程中性能最佳。 –XnoOpt -Xverify:none這兩個參數的使用雖然有測試過是否加入會影響性能，但是這兩個參數的真正意義原理不是很了解。
6、應用展現設計問題，如查詢類的不同機構的查詢默認情況下，登錄頁面后都會把所有機構的數據展現出來，經討論開發的改為該機構的用戶只能展現本機構的機構以及下級機構的數據。 而不是設計而所有的一級行機構都展現然后在根據權限問題查看只能查看本機構的數據。而且也是要用的時候才去展現機構樹，而不是每次登錄都刷新展現加載一次。
經這些調整后響應時間從10個用戶五十幾秒，到50用戶報表生成響應時間4.46S。
版權聲明：本文出自 泊涯 的51Testing軟件測試博客：http://www.51testing.com/?240349