性能問題表現第一種

小規模使用的時候性能表現很好，在大規模使用的時候，性能變得很差，業務響應時間隨業務壓力變得越來越慢

原因：代碼中對資源使用產生的瓶頸，後續的請求在資源(cpu、內存、鎖、線程池)上排隊

例子： 沒有索引的表的查詢 隨著業務量增加，表的行數快速增加，查詢越來越慢

性能測試解決的大部分問題是這種類型

性能問題表現第二種

在一定壓力情況下，應用的性能突然變差或者不可使用

原因：應用突然進入了一個異常邏輯，占用了很多資源，並且無法從異常狀態下退出

例子：fetion 後臺 初期版本中使用同步的socket連接，網絡單點異常的時候，全網的服務都不可用。

性能測試很難解決這種類型的性能問題。很難定位異常邏輯是什麽。

性能問題表現第三種

在壓力大於某個閥值的情況下，總會出現少量業務錯誤

原因：業務邏輯考慮不嚴密，導致少量流程不是按照期望發生

例子：取一個值做uniquekey值，鎖保護不夠導致，取值不唯一。

性能測試能夠很好的解決這類問題。

一些基本概念詳細解析

響應時間

Response time是性能測試中考察被測試軟件性能的一個指標；

Response time包括從客戶端請求發出開始，到reponse 應答回來後的時間總和，可能包括：

網絡傳輸

cpu上可執行隊列的等待時間

cpu計算

線程執行sleep語句的時間

鎖、閂的等待時間

磁盤io等待時間等。

吞吐量tps

吞吐量 tps是考察性能的另一個指標；

單位時間內完成業務量的多少，tps 是一個具體的常用的指標，每秒鐘完成的業務個數。

通常的誤會是認為response time一定會影響tps，這個不一定成立

並發

並發是指同時被處理的請求個數，同時處理可以有2個含義

同時都在線程堆棧上的請求

指在正在cpu上處理的請求

這裏指得是後者。

那麽最大的tps = Concurrency*1000 /請求在cpu上的處理時間(ms)

思考時間

Think Time思考時間 Think time是在測試代碼中出現的概念，為了在測試代碼中模擬時間用戶的思考時間而加的sleep時間，2個作用

第一作用是控制測試代碼的業務執行速度，完美地執行出預計的場景

模擬實際用戶執行的思考時間

有狀態的服務 很重要

無狀態的服務 不重要

測試壓力 business load

測試壓力是什麽？或者是客戶做了什麽導致服務器產生壓力

對於無狀態服務器，客戶端的壓力來源於客戶端的請求數/秒

對於有狀態服務器，客戶端的壓力是客戶端的在服務器的留存信息和rps。

數據庫是一個有狀態的服務器

有狀態的服務器更容易有性能問題

性能測試過程

完美的測試過程

完美的性能測試就是軟件在現網上實際運行的過程

實驗室狀態下永遠也無法完全模擬

性能測試無法找到所有的問題

性能測試方案

定義了在影響軟件運行性能的各個方面采用什麽樣的方法和策略模擬真實的情況，達到盡量真實模擬的目的。

非常重要， 決定了測試的成敗

基礎數據 : 測試之前，測試環境中已有的數據總和

關於基礎數據的原則

必須調查或者預測出數據庫表中每個表應該有多少行的數據。

而且數據取值要實際情況一樣豐富。

數據長度和實際情況相同

基礎數據決定著數據庫server的cpu、內存、io使用或其他多種資源的使用邏輯。

測試數據： 從基礎數據中選取的，參與到性能測試中的數據

選擇原則

在應用合理範圍內隨機挑選數據、挑選足夠的量。

挑選數據的方式通常影響數據庫的內存和io，有狀態服務的cpu和內存，線程、鎖等。

業務模型

測試完成哪些業務？完成速率？

建立業務模型的原則

最好是實際用戶行為的統計，如果沒有借助同類軟件的用戶行為統計，再沒有，根據有經驗人員的預估。

把用戶所有可能使用業務按使用頻繁程度排序，頻繁程度越高就越應該納入測試場景。

查看業務消耗計算資源的程度，預計消耗程度越大的越應該納入測試場景

建立業務模型的原則

多個業務在一起的復雜場景：把所有業務的在周期內的tps放在一起考察，一般情況下所有業務會有一致性的行為，即tps變化一致，取峰值階段的tps為測試通過標準。

如何有明顯不一致，需要取2到多個典型場景分別測試

測試場景

多大測試壓力（多少在線用戶或者rps是多少）

預估和實際預測的結果

測試多長時間？

無狀態的幾個小時

有狀態的幾天

硬件資源選擇的原則

大型分布式軟件的中每個角色都需要負載均衡的設計才能夠平滑擴展。 那麽測試環境只需要取得這樣一個環境的小的集合就可以了。

單個硬件設備最好使用上線後用的機器，因為不同設備之間的差異很大，無法但從cpu、內存、tpcc等指標來分析硬件之間的差異。

使用差異很大的設備測試只能定性的說明問題，無法定量

如何編寫測試代碼

能和實際的客戶一樣完成業務功能。這是最基本的能力，也是性能測試的基礎，必選

對每次與服務器的交互做嚴格的結果正確性檢查，保證功能執行的正確性。性能測試的目標不僅僅是提供測試的工作壓力，而且要保證測試功能的正確性，必選。

提供出錯日誌功能，這對於初步分析性能問題，或者測試代碼、被測試軟件的功能問題都是非常好的手段，可選

測試代碼在設計時要意識地保證數據庫的數據量的穩定性，可選。

提高測試代碼可配置性，保證在多種不同的測試場景下，測試場景可迅速建立，可選。

測試執行人的能力要求

測試人需要按照測試方案的要求，配置測試代碼和使用測試工具建立起方案中的測試場景，必選。

按照方案選擇合理的測試數據，必選。

測試人必須完全了解測試代碼的每個細節，如果在測試中發現測試任何錯誤，如果這個錯誤是測試代碼或者場景設置的問題，測試人有能力解決，必選。

判斷測試的結果分析是否有性能問題，必選。

對於服務方的問題，提供當時的上下文環境供開發和優化人員分析，可選。

能夠解決被測試軟件方由於配置錯誤等引起的簡單問題，可選。

軟件優化的基本步驟

性能問題有哪些？ cpu的瓶頸、內存的瓶頸、磁盤io的瓶頸、網絡io的瓶頸、線程之間同步的瓶頸等等

軟件優化好以後應該是什麽樣？特征

Tps 基本上和cpu使用率正相關

響應時間1-50 ms， tps 幾百幾千幾萬

參考測試設備 cpu等資源的情況

業務完成過程的復雜度

如果有性能瓶頸

首先排查其它瓶頸，保證tps和cpu正相關。

察看是否有cpu濫用的現象

“所有高cpu的問題都是不必要的循環引起的”---個人體會

沒有索引的表的查詢

應用本地沒有緩存，反復從數據庫或者其它應用獲取。

線程數太多，導致過多的上下文切換。

性能測試的限制

性能測試何時測不準？

性能測試有限性導致測不準

沒有測試到的場景和業務

軟件異常流程

硬件、網絡環境不一樣

比如客戶端特別移動客戶端網速慢

用戶行為變化導致的測不準

用戶數據增長導致的測不準

一個性能優化的例子

被測試系統問題介紹：一個 使用 dot net remoting的系統，在線上使用 1年多，突然出現 嚴重的outofmemory的問題

負載非常：忙時remoting的調用大約0.35個/秒

Cpu使用率低： 平均只有 1%

內存只升不降，在幾天內達到最大值，導致 outofmemory。如下圖：

從應用來看，每天只有20個客戶端在線使用，幾百個tcp連接怎麽來的？

原因：網絡異常，連接已經中斷，但server沒有感知。

應用部署在win2000上， win2000 無法感知連接異常

解決辦法：升級到win2003， 在註冊表增加tcp連接的檢測，每90秒檢查一次

性能測試的原則和方法