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性能測試中,更根據需要采集相應的參數進行分析。
| 指標 |
說明 |
| 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/秒!