一、事務(Transaction)javascript
在web性能測試中,一個事務表示一個「從用戶發送請求->web server接受到請求,進行處理-> web server向DB獲取數據->生成用戶的object(頁面),返回給用戶」的過程,通常的響應時間都是針對事務而言的。java
二、請求響應時間mysql
請求響應時間指的是從客戶端發起的一個請求開始,到客戶端接收到從服務器端返回的響應結束,這個過程所耗費的時間,在某些工具中,響應一般會稱爲「TTLB」,即"Time To Last Byte",意思是從發起一個請求開始,到客戶端接收到最後一個字節的響應所耗費的時間,響應時間的單位通常爲「秒」或者「毫秒」。一個公式能夠表示:響應時間=網絡響應時間+應用程序響應時間。ios
(1)在1秒鐘以內,頁面給予用戶響應並有所顯示,可認爲是「很不錯的」;web
(2)在1~2秒鐘內,頁面給予用戶響應並有所顯示,可認爲是「好的」;sql
(3)在2~3秒鐘內,頁面給予用戶響應並有所顯示,可認爲是「勉強接受的」;數據庫
(4)超過3秒就讓人有點不耐煩了,用戶極可能不會繼續等待下去;服務器
三、事務響應時間網絡
事務可能由一系列請求組成,事務的響應時間主要是針對用戶而言,屬於宏觀上的概念,是爲了向用戶說明業務響應時間而提出的.例如:跨行取款事務的響應時間就是由一系列的請求組成的.事務響應時間是直接衡量系統性能的參數.架構
四、併發用戶數
併發通常分爲2種狀況。一種是嚴格意義上的併發,即全部的用戶在同一時刻作同一件事情或者操做,這種操做通常指作同一類型的業務。好比在信用卡審批業務中,必定數目的擁護在同一時刻對已經完成的審批業務進行提交;還有一種特例,即全部用戶進行徹底同樣的 操做,例如在信用卡審批業務中,全部的用戶能夠一塊兒申請業務,或者修改同一條記錄。
另一種併發是廣義範圍的併發。這種併發與前一種併發的區別是,儘管多個用戶對系統發出了請求或者進行了操做,可是這些請求或者操做能夠是相同的,也能夠是不一樣的。對整個系統而言,仍然是有不少用戶同時對系統進行操做,所以也屬於併發的範疇。
能夠看出,後一種併發是包含前一種併發的。並且後一種併發更接近用戶的實際使用狀況,所以對於大多數的系統,只有數量不多的用戶進行「嚴格意義上的併發」。對於WEB性能測試而言,這2種併發狀況通常都須要進行測試,一般作法是先進行嚴格意義上的併發測試。嚴格意義上的用戶併發通常發生在使用比較頻繁的模塊中,儘管發生的機率不是很大,可是一旦發生性能問題,後果極可能是致命的。嚴格意義上的併發測試每每和功能測試關聯起來,由於併發功能遇到異常一般都是程序問題,這種測試也是健壯性和穩定性測試的一部分。
用戶併發數量:關於用戶併發的數量,有2種常見的錯誤觀點。 一種錯誤觀點是把併發用戶數量理解爲使用系統的所有用戶的數量,理由是這些用戶可能同時使用系統;還有一種比較接近正確的觀點是把在線用戶數量理解爲併發用戶數量。實際上在線用戶也不必定會和其餘用戶發生併發,例如正在瀏覽網頁的用戶,對服務器沒有任何影響,可是,在線用戶數量是計算併發用戶數量的主要依據之一。
五、吞吐量
指的是在一次性能測試過程當中網絡上傳輸的數據量的總和.吞吐量/傳輸時間,就是吞吐率.
對於交互式應用來講,吞吐量指標反映的是服務器承受的壓力,在容量規劃的測試中,吞吐量是一個重點關注的指標,由於它可以說明系統級別的負載能力。
吞吐率:
單位時間內網絡上傳輸的數據量,也能夠指單位時間內處理客戶請求數量。它是衡量網絡性能的重要指標,一般狀況下,吞吐率用「字節數/秒」來衡量,固然,你能夠用「請求數/秒」和「頁面數/秒」來衡量。其實,不論是一個請求仍是一個頁面,它的本質都是在網絡上傳輸的數據,那麼來表示數據的單位就是字節數。
不過以不一樣的方式表達的吞吐量能夠說明不一樣層次的問題。例如,以字節數/秒方式表示的吞吐量主要受網絡基礎設置、服務器架構、應用服務器制約;以請求數/秒方式表示的吞吐量主要受應用服務器和應用代碼的制約。
六、TPS(transaction per second)
每秒鐘系統可以處理的交易或者事務的數量.它是衡量系統處理能力的重要指標.
七、點擊率(Hit Per Second)
每秒鐘用戶向WEB服務器提 交的HTTP請求數.這個指標是WEB應用特有的一個指標:WEB應用是"請求-響應"模式,用戶發出一次申請,服務器就要處理一次,因此點擊是WEB應用可以處理的交易的最小單位.若是把每次點擊定義爲一個交易,點擊率和TPS就是一個概念.容易看出,點擊率越大,對服務器的壓力越大.點擊率只是一個性能參考指標,重要的是分析點擊時產生的影響。
須要注意的是,這裏的點擊並不是指鼠標的一次單擊操做,由於在一次單擊操做中,客戶端可能向服務器發出多個HTTP請求.
點擊率能夠看作是TPS的一種特定狀況。點擊率更能體現用戶端對服務器的壓力。TPS更能體現服務器對客戶請求的處理能力。
八、資源利用率
指的是對不一樣的系統資源的使用程度,例如服務器的CPU利用率,磁盤利用率等.資源利用率是分析系統性能指標進而改善性能的主要依據,所以是WEB性能測試工做的重點.
資源利用率主要針對WEB服務器,操做系統,數據庫服務器,網絡等,是測試和分析瓶頸的主要參考.在WEB性能測試中,更根據須要採集相應的參數進行分析。
指標 |
說明 |
ProcessorTime |
服務器CPU佔用率,通常平均達到70%時,服務就接近飽和 |
Memory Available Mbyte |
可用內存數,若是測試時發現內存有變化狀況也要注意,若是是內存泄露則比較嚴重 |
Physicsdisk Time |
物理磁盤讀寫時間狀況 |
Web服務器指標
指標 |
說明 |
Requests Per Second(Avg Rps) |
平均每秒鐘響應次數=總請求時間 / 秒數 |
Avg time to last byte per terstion (mstes) |
平均每秒業務腳本的迭代次數 ,有人會把上面那個混淆 |
Successful Rounds |
成功的請求 |
Failed Requests |
失敗的請求 |
Successful Hits |
成功的點擊次數 |
Failed Hits |
失敗的點擊次數 |
Hits Per Second |
每秒點擊次數 |
Successful Hits Per Second |
每秒成功的點擊次數 |
Failed Hits Per Second |
每秒失敗的點擊次數 |
Attempted Connections |
嘗試連接數 |
數據庫服務器性能指標
指標 |
說明 |
User 0 Connections |
用戶鏈接數,也就是數據庫的鏈接數量 |
Number of deadlocks |
數據庫死鎖 |
Butter Cache hit |
數據庫Cache的命中狀況 |
系統的瓶頸定義
性能項 |
命令 |
指標 |
CPU限制 |
vmstat |
當%user+%sys超過80%時 |
磁盤I/O限制 |
Vmstat |
當%iowait超過40%(AIX4.3.3或更高版本)時 |
應用磁盤限制 |
Iostat |
當%tm_act超過70%時 |
虛存空間少 |
Lsps,-a |
當分頁空間的活動率超過70%時 |
換頁限制 |
Iostat, stat |
虛存邏輯卷%tm_act超過I/O(iostat)的30%,激活的虛存率超過CPU數量(vmstat)的10倍時 |
系統失效 |
Vmstat, sar |
頁交換增大、CPU等待並運行隊列 |
穩定系統的資源狀態
性能項 |
資源 |
評價 |
CPU佔用率 |
70% |
好 |
85% |
壞 |
|
90%+ |
不好 |
|
磁盤I/0 |
<30% |
好 |
<40% |
壞 |
|
<50%+ |
不好 |
|
網絡 |
<30%帶寬 |
好 |
運行隊列 |
<2*CPU數量 |
好 |
內存 |
沒有頁交換 |
好 |
每一個CPU每秒10個頁交換 |
壞 |
|
更多的頁交換 |
不好 |
該要求不包括文件上傳 等重量級接口
指標名稱
|
要求
|
優先級
|
備註
|
---|---|---|---|
響應時間 | 500 millisecond | 1 | |
請求成功率 | 99% | 2 | |
TPS | 在知足預期要求的狀況下服務器狀態穩定,單臺服務器TPS要求在1000左右 |
3 | |
資源使用率 | 要求在TPS正常幅度的狀況下資源使用率幅度平穩,服務器狀態平穩 | 3 | 要求接口的內部實現不能佔用太多資源 |
數據庫死鎖 | 0,要求接口在使用過程當中不會形成數據庫死鎖 | 1 | |
CPU限制 | 要求接口在使用過程當中不會出現大量的計算 | 3 | |
內存 | 要求接口在使用過程當中不會出現內存大量消耗的狀況 | 3 | |
指標名稱
|
要求
|
優先級
|
備註
|
---|---|---|---|
響應時間 | 500 millisecond | 1 | |
請求成功率 | 99% | 2 | |
TPS | 在知足預期要求的狀況下服務器狀態穩定,單臺服務器TPS要求在1000左右 |
3 | |
資源使用率 | 要求在TPS正常幅度的狀況下資源使用率幅度平穩,服務器狀態平穩 | 3 | 要求接口的內部實現不能佔用太多資源 |
數據庫死鎖 | 0,要求接口在使用過程當中不會形成數據庫死鎖 | 1 | |
CPU限制 | 要求接口在使用過程當中不會出現大量的計算 | 3 | |
內存 | 要求接口在使用過程當中不會出現內存大量消耗的狀況 | 3 |