方天T-ONE性能測試報告

2022-05-26

方天T-ONE的底層結構很強大,所有模塊都可以根據需要自行安裝和御載,所以用戶能像搭積木一樣建構自己期望的系統。即使完全不安裝與ERP相關的模塊,僅利用T-ONE自身的底層框架,也能構建出適合各種用途的系統。T-ONEB/S架構,後端基於C#.NET開發,前端基於HTML5Javascript技術開發,所有功能和操作界面都能在手機上使用,支持界面自適應。


測試目的


1) 在XD公司給定的硬件環境,網絡環境狀況,多並發用戶情況下,測試T-ONE系統的響應速度。

2) 根據測試結果,判斷T-ONE是否可以滿足XD公司的性能要求。


測試背景


1) XD公司全國各地工廠5家,分公司有55家,代理公司有125家。分佈於各地分公司的員工約1200名,預計3年內人數將達到1800人。

2) 在XD公司給定的硬件環境,網絡環境下,基於T-ONE的新系統能否滿足XD公司現在及將來發展後的性能要求。


測試範圍


本次測試在XD公司總部辦公室進行,主要測試伺服器的性能(包括T-ONE伺服器和SQL數據庫伺服器),不測試網絡狀況,不測試客戶機的狀況,不測試各地分公司的訪問狀況。


測試環境


【客戶機】

聯想筆記本電腦,i5雙核CPU,8G內存,SSD硬盤。

T-ONE伺服器】

XD公司虛擬機,12核CPU,16G內存

T-ONE數據庫伺服器】

XD公司虛擬機,12核CPU,16G內存

【網絡環境】

XD公司總部局域網,客戶機和伺服器間網絡狀況極好。


測試需求、內容、工具及方法


測試需求


本次測試需求是:

1) 測試XD公司700多名系統用戶(員工),高峰期200名用戶同時登錄系統的情況下,T-ONE系統的響應速度能否達到XD公司的要求。

2) 本次測試在XD公司總部辦公室進行,主要測試系統軟件及伺服器的性能,不考慮異地網絡延遲問題。


並發數估算


根據統計規律,軟件系統的並發用戶數(同時作業系統的用戶數)的估算公式如下:

(1) 平均並發用戶數: C = n * L/T

(2) 並發用戶數峰值: C』 ≈ C + 3 * C的平方根

公式(1)中,C是平均的並發用戶數;n是登錄用戶(在線用戶)的數量;L是登錄用戶的平均在線時間,T指考察的時間段長度。

公式(2)則給出了並發用戶數峰值的計算方式中,其中,C』指並發用戶數的峰值,C就是公式(1)中得到的平均的並發用戶數。該公式假設用戶行為符合泊松分佈規律。

XD公司的用戶情況如下:

1) 總用戶數是800,實測高峰在線用戶數200;

2) 大部分用戶(超過500)車間報工人員,系統登錄時間較短,平均每天在1小時以下,銷計畫和財務人員登錄時間較長,平均每天估算為4小時;

3) 所有用戶的每天的平均登錄時間估算為2小時;

4) 用戶只在上班時間使用系統,因而考察時間段為上班時間,8小時。

XD公司的並發用戶數估算如下:

平均並發用戶數 C = n * L/T = 200 * 2/8 = 50

並發用戶數峰值 C』 = C + 3 * C的平方根 = 50 + 3 * 7 = 71


用戶響應時間標準


軟件系統的用戶響應時間,業界有一個普遍的標準,即2/5/10原則。也就是說,用戶一次操作,如果系統在2秒之內響應,用戶會認為是「非常有吸引力」的用戶體驗;如果在5秒之內響應,會認為「比較不錯」的用戶體驗;如果在10秒內響應,會被認為「糟糕」的用戶體驗;如果超過10秒還沒有得到響應,那麼大多數用戶會認為這次請求是失敗的。


測試內容


本次測試根據XD公司的業務特點,測試了五個代表性操作:

1) 客戶查詢,輸入關鍵字,查詢客戶,測試系統響應時間;

2) 新建銷售合同,輸入客戶、課程等信息,點擊保存,測試系統響應時間;

3) 客戶打款單列表,點擊「客戶打款單」菜單,系統顯示打款單一覽,測試響應時間;

4) 打開打款單,隨機點擊一覽中的一條客戶打款單,測試系統響應時間;

5) 打款單審核,點擊打款單審核按鈕,測試系統響應時間。

為了分析不同並發用戶數情況下,系統的響應速度的變化,本次測試將依次測試1並發,50並發,100並發,150並發,200並發情況下,上述五個操作的響應時間。

本次測試系統導入了XD公司6萬多條客戶信息,創建了2萬多個模擬客戶合同。


測試工具


主要測試工具為JMeter 測試軟件,JMeter是一款廣泛應用的Web系統性能測試工具。

本次測試的輔助工具還有GOOGLE瀏覽器,Excel電子表格。

JMeter可以模擬多用戶並發向伺服器發送請求,並記錄每個請求,伺服器的響應時間。不過,由於T-ONE系統大量使用Ajax連接,每個頁面都會同時發出多個請求(根據頁面複雜度不同,少的2個請求,多的有20個請求),JMeter記錄的單個請求的響應時間並不能反映整個頁面的響應時間。

為了獲得整頁面的響應時間,測試中用JMeter模擬並發用戶操作,再通過瀏覽器訪問系統,記錄整頁面響應時間。


測試方法


本次測試採用的方法步驟說明如下:

1) 先用JMeter錄製客戶查詢、新建銷售合同、客戶打款單列表、打開打款單、打款單審核五個動作動作;

2) 修改錄製的腳本,主要是將session_id替換成變量;

3) 用JMeter模擬多用戶同時執行上述操作;

4) 同時用GOOGLE瀏覽器手工操作客戶查詢、新建銷售合同、客戶打款單列表、打開打款單、打款單審核五個動作,查看系統響應結果及時間;

5) 依次測試1用戶、50並發、100並發、150並發、200並發情況下系統響應時間。

JMeter模擬用戶向伺服器發出請求,截取伺服器的響應數據,響應時間等參數。JMeter可以開啟多線程,模擬多個並發用戶作業系統的情況。JMeter測試截圖如下:



在網絡狀況良好的情況下,連接建立時間、伺服器響應結果傳輸時間幾乎沒有。下圖是在網絡狀況較差情況下,打開銷售合同時候,記錄的頁面響應時間。這個截圖說明了:

1) 打開銷售合同頁面,系統發起了10個Ajax調用;

2) 每個Ajax調用包括連接建立時間(灰色),伺服器響應時間(紫色),結果傳輸時間(綠色);

3) 兩個Ajax調用之間的間隔時間是本地Java script執行時間;

4) 同一頁面的Ajax調用存在並發調用(同時調用)的情況;

5) 包括所有Ajax的調用時間,本地Java script的執行時間,整頁面的響應時間是1.49秒;


測試結果及分析


系統性能測試結果


並發數為1, 50, 100, 150, 200情況下,客戶查詢、新建銷售合同、客戶打款單列表、打開打款單、打款單審核五個操作的系統響應時間如下:



系統負載情況


當並發用戶數從1逐步增加到300時候,T-ONE伺服器的CPU使用率逐步上升。下圖記錄的是,測試工具JMeter從16:40測試開始,每3秒鐘增加一個並發測試用戶,至16:55,並發用戶達到300個,伺服器的CPU使用率情況。

從圖中可以看到,300並發用戶時候,CPU使用率約36%。


測試結果分析


1) 從測試結果來看,1個並發用戶和50個並發用戶,系統響應速度幾乎沒有變化,五個操作的響應時間都在2秒上下;

2) 100並發用戶時候,系統響應速度略有下降,響應速度在2秒至2.5秒之間;

3) 從100並發到200並發,系統響應速度略有波動,但都在2秒至3秒之間;

4) 以目前XD公司的用戶數800,連接用戶數200,平均並發用戶數50,峰值並發用戶數71的情況下,系統常見操作的響應時間在2.5秒以下;

5) 考慮到將來的發展,如果員工總數翻一倍,用戶數1600,連接用戶數400,平均並發用戶數100,峰值並發用戶數達到142人,系統常見操作的響應時間在3秒以內;

6) XD公司各分公司訪問系統時候,考慮到異地網絡延遲問題,正常情況下,系統響應時間在4秒內(考慮增加1秒的網絡延遲)。根據用戶響應時間標準,這個響應時間屬於「比較不錯」的用戶體驗(5秒以內)。


分享
下一篇:這是最後一篇
上一篇:這是第一篇