性能測試數據分析經驗(3)

　　經驗：有時取平均值會有較大的誤差，尤其是測試不完全正常的情況。這時需要仔細分析原始數據，排除造成誤差的數據，以系統穩定(正常)時的數據作為有效數據。這里excel圖表功能是一個非常好用的工具。

　　三.數據分析。

　　從業務流程中可以想象，fcgi端的TE_tpcall()時間似乎應該大致等于或略大于(網絡傳輸時間等等)svr_cc上服務總的時間加上排隊時間，而排隊時間應該這樣線性計算：前端并發數/服務端并發數*服務端服務單筆總的平均時間。但上表的實際數據是TE_tpcall()時間小于svr_cc上服務總的時間!類似的，browser端的時間和fcgi上fcgi進程處理時間也有這種現象，只是相差很小。

　　這是因為實際情況不是我們想象的那樣!SUN主機上即有客戶端cc1(包括FCGI)節點也有服務端cc2節點的進程和TE核心運行。如果cc1上只有一個fcgi進程(TE客戶端進程)串行發起業務，我們可以認為fcgi端的TE_tpcall()時間似乎應該大致等于或略大于(網絡傳輸時間等等)svr_cc上服務總的時間。而當cc1上有多個fcgi進程(TE客戶端進程)并發發起業務時，在處理一筆服務業務邏輯的時間段內，SUN上的 CPU時間還會分給其他客戶進程以及TE核心(處理其他事務)，這樣在客戶端并發情況下，每筆業務的服務端處理時間實際上包含一部分其他筆業務(客戶進程和TE核心)的處理時間里。而所有的業務都是如此，最終TE_tpcall()平均時間小于svr_cc上服務總的平均時間。

　　在cc1進程和cc2進程的關系中，由于他們在一臺主機上，并且cc1進程不在少數，因此上述兩個時間差別也較大。而在browser和cc1的關系中，可以排除客戶端進程的處理(因為在另外一臺機器上)對服務端的影響，而只有TE核心并行處理多個交易對單筆服務處理時間的影響。在測試環境下，服務業務處理時間是主要時間，TE處理時間相對很小，因此上述兩個時間差別也非常小。

　　經驗：在多前端并發情況下，前端等待服務端應答時間和服務端處理時間不是線性比例關系，會比預期線性比例關系算出的時間小。具體差別和測試環境配置有關系?？蛻舳撕头斩朔珠_在不同的機器上會更接近線性比例關系。

　　四.平均值以外的東西。

　　對測試原始數據取平均值可以對整個系統的性能有一個了解，但有時只看平均值會遺漏一些同樣有價值的東西。

　　取30_20_10_2測試中任一個svr_cc服務進程的原始數據，用excel讀入，計算每筆service_before_tpcall時間(該服務的主要業務邏輯時間，也是整個開戶業務中最耗時間的環節)，并制作service_before_tpcall時間隨筆數變化的圖表，我們可以看到服務業務邏輯隨數據庫中記錄數的變化規律，這顯然是平均值無法體現的。

　　從圖中可以看出，該業務邏輯時間的平均分布隨筆數的增加而增加，也就是說，該業務邏輯時間和數據庫中記錄數有關(因為開戶是插入操作，應該是該業務邏輯時間的平均分布隨數據庫記錄數的增加而增加)，在這種大型OLTP系統中，這種處理時間和數據庫記錄數有較大關系的現象是不好的。一般是因為數據庫索引設置問題，需要調整數據庫索引。

　　至于最后幾十筆的時間急劇減小，是因為在最后幾十筆時有些前端應用已經完成，對于后臺的壓力減小，服務處理時間自然減小，并且越到后來運行的前端應用越少，服務處理時間也越少。結合前面第二節的經驗，在這個例子中，因為這些無效數據只占全部數據很少一部分，它們不會對平均值產生太大的誤差。

　　經驗：有時平均值數據不能反映系統全部特性。尤其對于系統關鍵環節，必要時還對原始數據做進一步統計分析。

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