Web效能測試的部分概況一般來說，一個Web請求的處理包括以下步驟：

    （1）客戶傳送請求

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

   （3）web server向DB獲取資料；

   （4）webserver生成使用者的object(頁面)，返回給使用者。給客戶傳送請求開始到最後一個位元組的時間稱為響應時間（第三步不包括在每次請求處理中）。

指標的概念：

1.事務（Transaction）

      在web效能測試中，一個事務表示一個“從使用者傳送請求->web server接受到請求，進行處理-> webserver向DB獲取資料->生成使用者的object(頁面)，返回給使用者”的過程，一般的響應時間都是針對事務而言的。

2.請求響應時間

請求響應時間指的是從客戶端發起的一個請求開始，到客戶端接收到從伺服器端返回的響應結束，這個過程所耗費的時間，在某些工具中，響應通常會稱為“TTLB”，即"timeto lastbyte"，意思是從發起一個請求開始，到客戶端接收到最後一個位元組的響應所耗費的時間，響應時間的單位一般為“秒”或者“毫秒”。一個公式可以表示：響應時間＝網路響應時間+應用程式響應時間。標準可參考國外的3/5/10原則：

      （1）在3秒鐘之內，頁面給予使用者響應並有所顯示，可認為是“很不錯的”；

      （2）在3~5秒鐘內，頁面給予使用者響應並有所顯示，可認為是“好的”；

      （3）在5~10秒鐘內，頁面給予使用者響應並有所顯示，可認為是“勉強接受的”；

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

3、事務響應時間

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

4.併發使用者數

     併發一般分為2種情況。一種是嚴格意義上的併發，即所有的使用者在同一時刻做同一件事情或者操作，這種操作一般指做同一型別的業務。比如在信用卡審批業務中，一定數目的擁護在同一時刻對已經完成的審批業務進行提交；還有一種特例，即所有使用者進行完全一樣的操作，例如在信用卡審批業務中，所有的使用者可以一起申請業務，或者修改同一條記錄。

     另外一種併發是廣義範圍的併發。這種併發與前一種併發的區別是，儘管多個使用者對系統發出了請求或者進行了操作，但是這些請求或者操作可以是相同的，也可以是不同的。對整個系統而言，仍然是有很多使用者同時對系統進行操作，因此也屬於併發的範疇。

     可以看出，後一種併發是包含前一種併發的。而且後一種併發更接近使用者的實際使用情況，因此對於大多數的系統，只有數量很少的使用者進行“嚴格意義上的併發”。對於WEB效能測試而言，這2種併發情況一般都需要進行測試，通常做法是先進行嚴格意義上的併發測試。嚴格意義上的使用者併發一般發生在使用比較頻繁的模組中，儘管發生的概率不是很大，但是一旦發生效能問題，後果很可能是致命的。嚴格意義上的併發測試往往和功能測試關聯起來，因為併發功能遇到異常通常都是程式問題，這種測試也是健壯性和穩定性測試的一部分。

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

5.吞吐量

     指的是在一次效能測試過程中網路上傳輸的資料量的總和.吞吐量/傳輸時間,就是吞吐率.

6、TPS（transactionpersecond）

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

7、點選率

     每秒鐘使用者向WEB伺服器提交的HTTP請求數.這個指標是WEB應用特有的一個指標:WEB應用是"請求-響應"模式,使用者發出一次申請,伺服器就要處理一次,所以點選是WEB應用能夠處理的交易的最小單位.如果把每次點選定義為一個交易,點選率和TPS就是一個概念.容易看出,點選率越大,對伺服器的壓力越大.點選率只是一個性能參考指標,重要的是分析點選時產生的影響。需要注意的是,這裡的點選並非指滑鼠的一次單擊操作,因為在一次單擊操作中,客戶端可能向伺服器發出多個HTTP請求.

8.資源利用率

指的是對不同的系統資源的使用程度,例如伺服器的CPU利用率,磁碟利用率等.資源利用率是分析系統性能指標進而改善效能的主要依據,因此是WEB效能測試工作的重點.

資源利用率主要針對WEB伺服器,作業系統,資料庫伺服器,網路等,是測試和分析瓶頸的主要參考.在WEB效能測試中,更根據需要採集相應的引數進行分析。

通用指標（指Web應用伺服器、資料庫伺服器必需測試項)

Web伺服器指標

資料庫伺服器效能指標

系統的瓶頸定義

穩定系統的資源狀態

通俗理解：

日訪問量

常用頁面最大併發數

同時線上人數

訪問相應時間

案例：

最近公司一個專案，是個入口網站，需要做效能測試，根據專案特點定出了主要測試項和測試方案：

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

一種是測試伺服器長時間壓力下，使用者能否正常操作(使用者名稱引數化，迭代執行指令碼)

一種則需要測試伺服器能否接受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、伺服器方面：上面說的那樣的PCSERVER需要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/秒!

原文地址：http://blog.csdn.net/qiguiting/article/details/11584397（如有侵權，請聯絡博主刪除。）