Web性能測試

一 Web系統性能測試包括哪些方面
負載測試：在被測系統上不斷增加壓力 ，直到性能指標達到極限，響應時間超過預定指


標或者某種資源已經達到飽和狀態。這種測試可以找到系統的處理極限，為系統調優提供


依據。


大數據量測試：針對某些系統存儲、傳輸、統計查詢等業務進行大數據量的測試。


配置測試：通過測試找到系統各資源的最優分配原則。


可靠性測試：可以施加cpu資源保持70%-90%使用率的壓力，連續對系統加壓運行8小時，


然后根據結果分析系統是否穩定。即加載一定壓力的情況下，使系統運行一段時間。


并發測試：多以發現一些算法設計上的問題。


性能測試以用戶并發測試為主的測試。
性能測試主要是為了發現軟件問題和硬件瓶頸。


二 web性能測試基本性能指標
<一> Web性能測試的部分概況一般來說，一個Web請求的處理包括以下步驟：
（1）客戶發送請求
（2）web server接受到請求，進行處理；
（3）web server向DB獲取數據；
（4）webserver生成用戶的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秒就讓人有點不耐煩了，用戶很可能不會繼續等待下去；
3、事務響應時間
? 事務可能由一系列請求組成,事務的響應時間主要是針對用戶而言,屬于宏觀上的概念，


是為了向用戶說明業務響應時間而提出的.例如:跨行取款事務的響應時間就是由一系列的


請求組成的.事務響應時間是直接衡量系統性能的參數.
4.并發用戶數
并發一般分為2種情況。一種是嚴格意義上的并發，即所有的用戶在同一時刻做同一件事


情或者操作，這種操作一般指做同一類型的業務。比如在信用卡審批業務中，一定數目的


擁護在同一時刻對已經完成的審批業務進行提交；還有一種特例，即所有用戶進行完全一


樣的操作，例如在信用卡審批業務中，所有的用戶可以一起申請業務，或者修改同一條記


錄。
　　另外一種并發是廣義范圍的并發。這種并發與前一種并發的區別是，盡管多個用戶對


系統發出了請求或者進行了操作，但是這些請求或者操作可以是相同的，也可以是不同的


。對整個系統而言，仍然是有很多用戶同時對系統進行操作，因此也屬于并發的范疇。
　　可以看出，后一種并發是包含前一種并發的。而且后一種并發更接近用戶的實際使用


情況，因此對于大多數的系統，只有數量很少的用戶進行“嚴格意義上的并發”。對于


WEB性能測試而言，這2種并發情況一般都需要進行測試，通常做法是先進行嚴格意義上的


并發測試。嚴格意義上的用戶并發一般發生在使用比較頻繁的模塊中，盡管發生的概率不


是很大，但是一旦發生性能問題，后果很可能是致命的。嚴格意義上的并發測試往往和功


能測試關聯起來，因為并發功能遇到異常通常都是程序問題，這種測試也是健壯性和穩定


性測試的一部分。
用戶并發數量：關于用戶并發的數量，有2種常見的錯誤觀點。 一種錯誤觀點是把并發用


戶數量理解為使用系統的全部用戶的數量，理由是這些用戶可能同時使用系統；還有一種


比較接近正確的觀點是把在線用戶數量理解為并發用戶數量。實際上在線用戶也不一定會


和其他用戶發生并發，例如正在瀏覽網頁的用戶，對服務器沒有任何影響，但是，在線用


戶數量是計算并發用戶數量的主要依據之一。
5.吞吐量
指的是在一次性能測試過程中網絡上傳輸的數據量的總和.吞吐量/傳輸時間,就是吞吐率.
6、　TPS（transactionper second）
每秒鐘系統能夠處理的交易或者事務的數量.它是衡量系統處理能力的重要指標.
7、點擊率
每秒鐘用戶向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個系統


來壓一下看看，可能會出現以下情況：
　　1、服務器宕機；
　　2、客戶端宕機；
　　3、從某個時間開始服務器拒絕請求，客戶端上顯示的全是錯誤；
　　4、勉強測試完成，但網絡堵塞或測試結果顯示時間非常長。假設客戶端和服務器之


間百兆帶寬，百兆/10000=10K，那每個用戶只能得到10K，這個速度接近1個64K的MODEM上


網的速度；另外以上分析全都沒考慮系統的后臺，比如數據庫、中間件等。
　　1、服務器方面：上面說的那樣的PC SERVER需要50臺；
　　2、網絡方面：按每個用戶50K，那至少5根百兆帶寬獨享，估計僅僅網絡延遲就大概


是秒一級的；
　　3、如果有數據庫，至少是ORACLE，最好是SYSBASE，SQLSERVER是肯定頂不住的。數


據庫服務器至少需要10臺4CPU、16G內存的機器；
　　4、如果有CORBA，那至少再準備10臺4CPU、16G內存的機器；再加上負載均衡、防火


墻、路由器和各種軟件等，總之沒個1000萬的資金投入，肯定搞不定。
　　這樣的門戶系統，由于有用戶權限，所以并不象jackie所說大多是靜態頁面。但只要


是多服務器的集群，那么我們就可以通過1臺機器的測試結果來計算多臺機器集群后的負


載能力的，最多額外考慮一下負載均衡和路由上的壓力，比如帶寬、速度、延遲等。但如


果都是在1臺機器上變化，那我們只能做一些指標上的計算，可以從這些指標上簡單判斷


一下是否不可行，比如10萬并發用戶卻只有1根百兆帶寬，那我們可以計算出每個用戶只


有1K帶寬，這顯然是不可行的。但實際的結果還是需要測試了才知道，畢竟系統壓力和用


戶數量不是線性變化的。
　　這一類系統的普遍的成熟的使用，以及很多軟件在方案設計后就能夠大致估算出系統


的性能特點，都導致了系統在軟件性能方面調優的比例并不大（當然不完全排除后期針對


某些代碼和配置進行優化后性能的進一步提高），更多的都是從硬件方面來考慮，比如增


加內存、硬盤做RAID、增加帶寬、甚至增加機器等。
　　網絡技術中的10M 帶寬指的是以位計算， 就是 10M bit /秒 ，而下載時的速度看到


的是以字節（Byte）計算的，所以10M帶寬換算成字節理論上最快下載速度為： 1.25 M?


Byte/秒!

總結

以上是生活随笔為你收集整理的Web性能测试的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。