web性能指標

Web性能測試的部分概況通常來講，一個Web請求的處理包括如下步驟：

（1）客戶發送請求

（2）web server 接受到請求，進行處理；

（3）web server 向DB獲取數據；

（4）web server生成用戶的object(頁面)，返回給用戶。給客戶發送請求開始到最後一個字節的時間稱爲響應時間（第三步不包括在每次請求處理中）。

1.事務（Transaction）

在web性能測試中，一個事務表示一個「從用戶發送請求->web server接受到請求，進行處理-> web server向DB獲取數據->生成用戶的object(頁面)，返回給用戶」的過程，通常的響應時間都是針對事務而言的。

2.請求響應時間

請求響應時間指的是從客戶端發起的一個請求開始，到客戶端接收到從服務器端返回的響應結束，這個過程所耗費的時間，在某些工具中，響應一般會稱爲「TTLB」，即"time to last byte"，意思是從發起一個請求開始，到客戶端接收到最後一個字節的響應所耗費的時間，響應時間的單位通常爲「秒」或者「毫秒」。一個公式能夠表示：響應時間＝網絡響應時間+應用程序響應時間。標準可參考國外的3/5/10原則：

（1）在3秒鐘以內，頁面給予用戶響應並有所顯示，可認爲是「很不錯的」；

（2）在3~5秒鐘內，頁面給予用戶響應並有所顯示，可認爲是「好的」；

（3）在5~10秒鐘內，頁面給予用戶響應並有所顯示，可認爲是「勉強接受的」；

（4）超過10秒就讓人有點不耐煩了，用戶極可能不會繼續等待下去；

三、事務響應時間

  事務可能由一系列請求組成,事務的響應時間主要是針對用戶而言,屬於宏觀上的概念，是爲了向用戶說明業務響應時間而提出的.例如:跨行取款事務的響應時間就是由一系列的請求組成的.事務響應時間是直接衡量系統性能的參數.

4.併發用戶數

併發通常分爲2種狀況。一種是嚴格意義上的併發，即全部的用戶在同一時刻作同一件事情或者操做，這種操做通常指作同一類型的業務。好比在信用卡審批業務中，必定數目的擁護在同一時刻對已經完成的審批業務進行提交；還有一種特例，即全部用戶進行徹底同樣的 操做，例如在信用卡審批業務中，全部的用戶能夠一塊兒申請業務，或者修改同一條記錄。

　　另一種併發是廣義範圍的併發。這種併發與前一種併發的區別是，儘管多個用戶對系統發出了請求或者進行了操做，可是這些請求或者操做能夠是相同的，也能夠是不一樣的。對整個系統而言，仍然是有不少用戶同時對系統進行操做，所以也屬於併發的範疇。

　　能夠看出，後一種併發是包含前一種併發的。並且後一種併發更接近用戶的實際使用狀況，所以對於大多數的系統，只有數量不多的用戶進行「嚴格意義上的併發」。對於WEB性能測試而言，這2種併發狀況通常都須要進行測試，一般作法是先進行嚴格意義上的併發測試。嚴格意義上的用戶併發通常發生在使用比較頻繁的模塊中，儘管發生的機率不是很大，可是一旦發生性能問題，後果極可能是致命的。嚴格意義上的併發測試每每和功能測試關聯起來，由於併發功能遇到異常一般都是程序問題，這種測試也是健壯性和穩定性測試的一部分。

用戶併發數量：關於用戶併發的數量，有2種常見的錯誤觀點。 一種錯誤觀點是把併發用戶數量理解爲使用系統的所有用戶的數量，理由是這些用戶可能同時使用系統；還有一種比較接近正確的觀點是把在線用戶數量理解爲併發用戶數量。實際上在線用戶也不必定會和其餘用戶發生併發，例如正在瀏覽網頁的用戶，對服務器沒有任何影響，可是，在線用戶數量是計算併發用戶數量的主要依據之一。

5.吞吐量

指的是在一次性能測試過程當中網絡上傳輸的數據量的總和.吞吐量/傳輸時間,就是吞吐率.

六、　TPS（transaction per second）

每秒鐘系統可以處理的交易或者事務的數量.它是衡量系統處理能力的重要指標.

七、點擊率

每秒鐘用戶向WEB服務器提 交的HTTP請求數.這個指標是WEB應用特有的一個指標:WEB應用是"請求-響應"模式,用戶發出一次申請,服務器就要處理一次,因此點擊是WEB應用可以處理的交易的最小單位.若是把每次點擊定義爲一個交易,點擊率和TPS就是一個概念.容易看出,點擊率越大,對服務器的壓力越大.點擊率只是一個性能參考指標,重要的是分析點擊時產生的影響。須要注意的是,這裏的點擊並不是指鼠標的一次單擊操做,由於在一次單擊操做中,客戶端可能向服務器發出多個HTTP請求.

8.資源利用率

指的是對不一樣的系統資源的使用程度,例如服務器的CPU利用率,磁盤利用率等.資源利用率是分析系統性能指標進而改善性能的主要依據,所以是WEB性能測試工做的重點.

資源利用率主要針對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個頁交換 壞

更多的頁交換 不好

　　通俗理解：

　　日訪問量

　　經常使用頁面最大併發數

　　同時在線人數

　　訪問相應時間

　　案例：

　　最近公司一個項目，是個門戶網站，須要作性能測試，根據項目特色定出了主要測試項和測試方案：

　　一種是測試幾個經常使用頁面能接受的最大併發數(用戶名參數化，設置集合點策略)

　　一種是測試服務器長時間壓力下，用戶可否正常操做(用戶名參數化，迭代運行腳本)

　 　一種則須要測試服務器可否接受10萬用戶同時在線操做，若是是用IIS作應用服務器的話，單臺可承受的最大併發數不可能達到10萬級，那就必需要使用集 羣，經過多臺機器作負載均衡來實現；若是是用websphere之類的應用服務器的話，單臺可承受的最大併發數能夠達到10萬級，但爲性能考慮仍是必需要 使用集羣，經過多臺機器作負載均衡來實現；一般有1個簡單的計算方式，1個鏈接產生1個session，每一個session在服務器上有個內存空間大小的 設置，在NT上是3M，那麼10萬併發就須要300G內存，固然實際使用中考慮其餘程序也佔用內存，因此準備的內存數量要求比這個還要多一些。還有10萬個用戶同時在線，跟10萬個併發數是徹底不一樣的2個概念。這個樓上已經說了。但如何作這個轉換將10萬個同時在線用戶轉換成多少個併發數呢？這就必需要有大量的歷史日誌信息來支撐了。系統日誌須要有同時在線用戶數量的日誌信息，還須要有用戶操做次數的日誌信息，這2個數據的比例就是你同時在線用戶轉換到併發數的比例。另外根據經驗統計，對於1個JAVA開發的WEB系 統（別的我沒統計過，給不出數據），通常1臺雙CPU、2G內存的服務器上可支持的最大併發數不超過500個（這個狀態下大部分操做都是超時報錯並且服務 器很容易宕機，其實沒什麼實際意義），可正常使用（單步非大數據量操做等待時間不超過20秒）的最大併發數不超過300個。假設你的10萬同時在線用戶轉 換的併發數是9000個，那麼你最少須要這樣的機器18臺，建議很多於30臺。固然，你要是買個大型服務器，裏面裝有200個CPU、256G的內存，千 兆光纖帶寬，就算是10萬個併發用戶，那速度，也絕對是嗖嗖的。

　　另外暴寒1下，光設置所有進入運行狀態就須要接近6個小時。具體的能夠拿1個系統來壓一下看看，可能會出現如下狀況：

　　一、服務器宕機；

　　二、客戶端宕機；

　　三、從某個時間開始服務器拒絕請求，客戶端上顯示的全是錯誤；

　　四、勉強測試完成，但網絡堵塞或測試結果顯示時間很是長。假設客戶端和服務器之間百兆帶寬，百兆/10000=10K，那每一個用戶只能獲得10K，這個速度接近1個64K的MODEM上網的速度；另外以上分析全都沒考慮系統的後臺，好比數據庫、中間件等。

　　一、服務器方面：上面說的那樣的PC SERVER須要50臺；

　　二、網絡方面：按每一個用戶50K，那至少5根百兆帶寬獨享，估計僅僅網絡延遲就大概是秒一級的；

　　三、若是有數據庫，至少是ORACLE，最好是SYSBASE，SQLSERVER是確定頂不住的。數據庫服務器至少須要10臺4CPU、16G內存的機器；

　　四、若是有CORBA，那至少再準備10臺4CPU、16G內存的機器；再加上負載均衡、防火牆、路由器和各類軟件等，總之沒個1000萬的資金投入，確定搞不定。

　 　這樣的門戶系統，因爲有用戶權限，因此並不象jackie所說大可能是靜態頁面。但只要是多服務器的集羣，那麼咱們就能夠經過1臺機器的測試結果來計算多 臺機器集羣后的負載能力的，最多額外考慮一下負載均衡和路由上的壓力，好比帶寬、速度、延遲等。但若是都是在1臺機器上變化，那咱們只能作一些指標上的計 算，能夠從這些指標上簡單判斷一下是否不可行，好比10萬併發用戶卻只有1根百兆帶寬，那咱們能夠計算出每一個用戶只有1K帶寬，這顯然是不可行的。但實際 的結果仍是須要測試了才知道，畢竟系統壓力和用戶數量不是線性變化的。

　 　這一類系統的廣泛的成熟的使用，以及不少軟件在方案設計後就可以大體估算出系統的性能特色，都致使了系統在軟件性能方面調優的比例並不大（固然不徹底排 除後期針對某些代碼和配置進行優化後性能的進一步提升），更多的都是從硬件方面來考慮，好比增長內存、硬盤作RAID、增長帶寬、甚至增長機器等。

　　網絡技術中的10M 帶寬指的是以位計算， 就是 10M bit /秒 ，而下載時的速度看到的是以字節（Byte）計算的，因此10M帶寬換算成字節理論上最快下載速度爲： 1.25 M Byte/秒!