我以為福建移動BOSS系統做的一個小規模的性能測試為例,談談我在數據分析中的一些經驗。測試用例,模式如下圖。
一臺Linux模擬Browser(簡稱browser)向主機SUN發 HTTP請求,SUN上啟動Apache Web Server將請求交給FCGI程序。FCGI程序作為TE節點CC1(簡稱fcgi)的客戶進程發起TE事務,經GT1名字服務向CC2 (簡稱svr_cc)發送一個分支,CC2 上服務嵌套經GT1名字服務向ACCTFZ(在HP上,簡稱svr_ac)發送一個分支。
測試3種壓力情況,即10browser/10fcgi/5svr_cc服務進程/2svr_ac服務進程,20browser/20fcgi /10svr_cc服務進程/2svr_ac服務進程,30browser/20fcgi/10svr_cc服務進程/2svr_ac服務進程。
一.記錄數據。
各個部分的應用程序在程序中關鍵地方記錄時間,精確到微秒(毫秒也可以),并按一定格式寫入日志文件。這樣可以并計算相同應用相臨時間點之間的平均時間差(編程序分析日志文件或用excel導入)。有了時間差,才能分析出整個系統性能的瓶頸(處理慢的環節)。下面給出一個fcgi進程(也是TE客戶端進程)的日志文件片段。
[19:21:32.628.512] begin_tpbegin
[19:21:32.628.833] end_tpbegin
[19:21:32.628.944] begin_tpsetbranch
[19:21:32.629.053] end_tpsetbranch
[19:21:32.629.487] begin_tpcall
[19:21:37.102.996] end_tpcall
[19:21:37.103.806] begin_tpcommit
[19:21:37.432.253] end_tpcommit
[19:21:40.405.345] begin_tpbegin
[19:21:40.405.532] end_tpbegin
[19:21:40.405.639] begin_tpsetbranch
[19:21:40.405.742] end_tpsetbranch
[19:21:40.406.175] begin_tpcall
[19:21:46.732.888] end_tpcall
[19:21:46.733.650] begin_tpcommit
[19:21:46.832.538] end_tpcommit
第一個字段是時間點時間,第二個字段是該時間點描述串,兩個字段用空格間隔。從這個文件可以看出,fcgi進程是循環處理業務的。 begin_tpbegin處開始一筆業務,begin_tpcall和end_tpcall之間是TE_tpcall()發起請求到收到應答的時間,begin_tpbegin和end_tpbegin之間是TE_tpcommit()發起提交到收到提交應答的時間。而end_tpcommit到 begin_tpcall是fcgi進程從一筆業務結束到開始下一筆業務的時間,在這里也就是fcgi進程從Web Server獲取HTTP請求的時間。
從這種格式的原始數據文件可以編程序計算出相臨時間點之間的時間差,并可以計算出所有交易的平均時間差。也可以用excel打開這種格式的原始數據文件,按空格分隔各列,讀入excel后就可以使用excel提供的函數(入SEC()函數從hh:mm:ss時間格式換算成秒)和公式計算時間差和平均值,以及產生圖表等等。事實證明excel的功能是十分強大和方便的。
二.誤差的判斷和排除。
根據原始數據統計出的3種壓力情況下fcgi各點時間如下。10_10_5_2(ms) | 20_20_10_2(ms) | 30_20_10_2(ms) | ||
TPC(筆/秒) | 2.16967 | 2.28571 | 2.21911 | |
fcgi | receive from fcgi | 343 | 931 | 1676 |
tpcall | 4096 | 7614 | 8067 | |
tpcommit | 176 | 204 | 205 | |
total_fcgi | 4615 | 8749 | 9731 |
比較10_10_5_2和20_20_10_2,由于20_20_10_2在SUN主機上啟動fcgi進程和svr_cc服務進程數都比 10_10_5_2多,SUN上的壓力也較大,因此receive from fcgi的時間也較大是合理的。比較20_20_10_2和30_20_10_2,2在SUN主機上,壓力沒有變化,僅是有HTTP請求的排隊(因為 browser進程比fcgi進程多),SUN上的壓力應基本一樣,而receive from fcgi的時間有較大的差別是不合理的??紤]到在測30_20_10_2并發時有失敗業務,懷疑可能由于browser上加給web Server過大造成失敗。這次性能測試主要測試系統正常(業務正常,壓力情況是預計壓力情況)時的系統情況,而在有業務失敗時往往有些前端進程工作不正常,不能對后臺造成預期的壓力,這時取平均值可能會造成較大誤差。
原文轉自:http://www.uml.org.cn/Test/200505265.htm