性能測試及性能調優概述(2)

　　數據值中的不連續峰值 - 不必太重視數據中偶爾的峰值。這些峰值可能是由于進程的啟動，并不是該進程隨時間改變的計數器值的準確反映。尤其是平均計數器可以導致峰值隨時間停留的效果。

　　監視一段延長的時期 - 建議使用圖形代替報告或直方圖，因為后兩種視圖僅顯示最后的值和平均值。結果，當查找峰值時，可能得不到這些值的準確反映。

　　排除啟動事件 - 除非有特殊的原因需要將啟動事件包含在數據中，否則排除這些事件，因為它們產生的臨時性高峰值往往歪曲了整體性能結果。

　　零值或缺少的數據 - 調查所有出現的零值或缺少的數據。這些零值或缺少的數據會妨礙建立有意義的基準。

　　配置

　　收集了數據并完成結果分析后，可以確定系統的哪部分最適合進行配置更改，然后實現此更改。

　　實現更改的最重要規則是：一次僅實現一個配置更改?？雌饋砼c單個組件相關的問題可能是由涉及多個組件的瓶頸導致的。因此，分別處理每個問題很重要。如果同時進行多個更改，將不可能準確地評定每次更改的影響。

　　測試

　　實現了配置更改后，必須完成適當級別的測試，確定更改對調整的系統所產生的影響。在這一點上，這是確定更改是否有如下影響的問題：

　　性能提高 - 更改提高了性能嗎?如果是，提高了多少?

　　性能下降 - 更改在其他位置導致了瓶頸嗎?

　　對性能沒有影響 - 更改對性能到底有何顯著的影響?

　　如果幸運，性能提高到預期的水平，這時便可以退出。如果不是這樣，則必須重新逐步進行調整循環。

　　提示 可以從監視日志文件(可導出到 Microsoft Excel)和事件日志中獲取測試所產生的監視結果。

　　測試時務必要：

　　檢查用于測試的應用程序的正確性和性能，查找內存泄漏和不正常的客戶端請求響應延遲。

　　確保所有測試都正常進行。

　　確?？梢允褂孟嗤氖聞栈旌虾拖嗤目蛻舳松上嗤呢撦d來重復所有測試。

　　文檔更改和結果。

　　在每遍測試中，運行一系列完全相同的性能測試;否則，無法分辨不同的結果是由于測試中的改動還是應用程序更改造成的。使盡可能多的性能測試操作自動進行有助于消除因操作者造成的差異。

　　其他表面上是良性的因素影響性能測試的結果，如應用程序在測試開始前運行的時間。正如冷的汽車引擎與熱引擎的性能不同，長時間運行的應用程序由于內存碎片這樣的因素，其性能可能與剛啟動的應用程序不同。

　　定義性能測試

　　性能測試期間，測量和記錄性能目標中指定的度量標準值。達到全部性能度量標準(如思考時間、事務混合等)很重要。在這些約束下，測試應盡可能實際。例如，對應用程序進行測試，確定它在許多客戶端同時訪問它時的性能。多線程測試應用程序可以用可復制的方式模擬多個客戶端，每個線程表示一個客戶端。如果應用程序訪問數據庫，則數據庫應包含實際數目的記錄，并且測試應使用數據項的隨機(但有效)值。如果測試數據庫太小，數據庫服務器的緩存效果將產生不符合實際情況的測試結果。如果輸入或訪問數據的方式不符合實際情況，則結果也可能不符合實際情況。例如，在主鍵上按字母順序創建新數據是不太可能的。

　　通常，測試裝置必須接受用戶指定的輸入參數，如事務混合、思考時間、客戶端數目等。然而，測試裝置本身可以規定創建實際的隨機數據的規則。

　　創建了驅動應用程序的測試裝置后，應該將所有運行測試的不變條件記入文檔。最起碼，這些條件應包括運行測試裝置所需的輸入參數。另外，應將如何設置運行測試的數據庫記入文檔。說明中應指定數據庫不應包含前一遍測試所做的更改。說明中還應指定用于測試的計算機配置。在不同于應用程序所在的另一臺計算機上運行測試裝置，因為這樣設置更接近生產環境。

　　確定基準性能

　　確定了性能目標并制定了性能測試后，運行一次測試以建立基準。驗證環境與生產環境越相似，應用程序部署后的性能令人滿意的可能性就越大。因此，一開始有一個符合實際情況的驗證環境很重要。

　　幸運的話，基準性能將符合性能目標，并且應用程序不需要任何調整。但更可能的情況是，基準性能不令人滿意。然而，記錄初始測試環境和基準結果可以為調整工作提供堅實的基礎。

原文轉自：http://www.uml.org.cn/Test/200512261.htm