性能測試指標的基本概念

吞吐量/處理能力
處理能力又叫吞吐量，指的是單位時間內處理的客戶端請求數量。通常情況下，吞吐量用請求數/秒Or頁面數/秒來衡量。從業務角度看，吞吐量也可以用訪問人數/天Or頁面訪問量/天來衡量。

負載
負載分爲客戶端負載和服務器端負載客戶端負載的通俗解釋就是有多少個用戶在同時使用軟件服務器端負載的通俗解釋就是有多少個請求同時到達了服務器端，要求服務器進行處理。例如，某個網站當前有10000個人在線訪問，從他們的客戶端層面看過去，這個負載就是客戶端負載，爲10000。若某個網站當前有10000個人在線訪問，某一時刻，從他們的客戶端同時發出了1000個頁面的請求到服務器，從服務器端層面看過去，這個負載就是服務器端負載，爲1000。

響應時間
響應時間是可以判斷一個被測應用系統是否存在性能瓶頸的最直觀的要素。例如，在執行完性能測試後，發現某個交易的“平均響應時間”爲8秒，超過了預先確定下來的性能指標“該交易的性能指標爲平均響應時間要小於等於3秒”。此時，就可以認爲被測應用系統存在性能瓶頸了，要利用一定的手段去探查被測應用系統中哪個地方引起了系統的處理效率低以及低的原因了。響應時間一般包括最大響應時間和平均響應時間，響應時間包括網絡上的傳輸時間，WEB服務器上處理時間、APP服務器上的處理時間、DB服務器上的處理時間，響應時間不包括瀏覽器上的內容顯示時間。

同時在線用戶
對於一個網站來講，當一個用戶登錄到該網站的首頁後，開始在該網站上進行各種操作，包括瀏覽網頁、檢索內容、提交表單等，這個過程中的用戶稱爲在線用戶。若同一時間點或同一個時間段內，有很多這樣的用戶在訪問該網站，這些用戶統稱爲該網站的同時在線用戶。同時在線用戶的另一層理解是，將應用系統整體看作是一個黑盒子，從用戶的客戶端層面看向系統，總共有多少個人在使用它。當進行性能測試時，如果你使用的是同時在線用戶，則可以稱之爲同時在線負載。

超級併發用戶
對於一個網站來講,可能存在WEB服務器、應用服務器、數據庫服務器三個層次，而用戶所使用的瀏覽器是在最外面的客戶端層面。如果某個時間點或時間段內，共有1000個用戶同時在線，他們進行着各種各樣的操作，而某個時間點上可能存在10個左右的用戶同時進行了一個或多個操作，導致WEB服務器同時接收到了10個左右的交易請求，我們稱這個10個左右的用戶爲超級併發用戶。當進行性能測試時，如果你使用的是超級併發用戶，則可以稱之爲超級併發負載。

性能測試腳本
腳本是用負載模擬工具開發出來的。腳本是一些代碼的組合體，它用代碼來實現用戶對應用系統的操作。例如,你在一個網站上訪問首頁、輸入用戶名和密碼後點擊登錄按鈕進行登錄，這是用戶對應用系統的兩步操作內容，在腳本中則包含了實現這兩個操作步驟的代碼。如果你要模擬10000個用戶的負載，這10000個用戶中50%進行首頁的訪問、20%進行註冊、20%進行查詢、10%進行某個頁面的瀏覽，則你需要製作5個腳本，分別是首頁訪問腳本、註冊腳本、查詢腳本、頁面瀏覽腳本。

事務
事務是腳本的一個特性，每個事務都包含開始事務和結束事務。事務用來衡量腳本中一行代碼或多行代碼的執行所耗費的時間。你可以將開始事務放置在腳本中某行代碼的前面，將結束事務放置在該行代碼的後面，在該腳本的虛擬用戶運行時，這個事務將衡量該行代碼的執行花費了多長時間。

交易
交易分爲業務層面和技術層面兩種定義。業務層面交易是指完成一次完整的業務操作，例如進行一次取款、查詢操作。技術層面的交易是指進行一次應用程序至應用程序、或者應用程序至數據庫的系統操作。一般的一筆業務交易由多筆技術交易組成，根據業務交易的複雜度和系統應用架構的不同，其比例大致爲1：2-1：10。

TPS與HPS
TPS (Transactions Per Second)是估算應用系統性能的重要依據。其意義是應用系統每秒鐘處理完成的交易數量，尤其是交易類系統。一般的，評價系統性能均以每秒鐘完成的技術交易的數量來衡量。系統整體處理能力取決於處理能力最低模塊的TPS值。依據經驗，應用系統的處理能力一般要求在10-100左右。不同應用系統的TPS有着十分大的差別，一般需要通過性能測試進行準確估算。當系統沒有達到性能瓶頸時，TPS隨着負載的增加呈近似線性增長，當接近性能瓶頸時出現拐點；如果系統健壯性較好，在到達性能瓶頸後，TPS基本保持水平，不會再隨着負載的增加而有顯著增長；而如果系統存在比較嚴重的性能問題，當到達性能瓶頸後，TPS會出現明顯的下降趨勢。HPS：(Hits per Second)每秒點擊次數，是指在一秒鐘的時間內用戶對Web頁面的鏈接、提交按鈕等點擊總和它一般和TPS成正比關係，是B/S系統中非常重要的性能指標之一。
TPS可以有多種衡量單位，在進行性能測試的業務模型分析時使用，例如：
（1）在稅務系統中，可以用“系統每個月要處理10萬用戶的業務操作”，這裏的TPS用企業數/月來衡量；（2）在稅務系統中，也可以用“系統在第七天的8個小時內要處理4萬用戶的業務操作”，這裏的TPS用企業數/天來衡量；（3）在稅務系統中，也可以用“系統在第七天的10點到11點之間要處理1.2萬用戶的3種繳稅交易操作，即3.6萬次繳稅交易操作”，這裏的TPS用交易數/小時來衡量；（4）在稅務系統中，也可以用“系統在第七天的10點到11點之間要處理1.2萬用戶的3種繳稅交易操作，即3.6萬次繳稅交易操作，每次繳稅交易要從客戶端向服務器發送平均10次HTTP請求，即36萬次HTTP請求操作”，這裏的TPS用請求數/小時來衡量。
HPS是用來衡量很多用戶使用客戶端進行操作，向服務器發送請求的效率。我們認爲HPS表現的是最終用戶的整體行爲，是衡量在線負載程度的一個指標。而TPS表現的是服務器端的程序行爲，是衡量服務器處理能力高低的一個主要指標。
例如：HPS＝“點擊次數/秒”；TPS＝“處理事務數/秒”，HPS與TPS沒有絕對的關係。

性能測試實現的準確性
在進行了正確的性能測試分析後，獲得了正確的性能測試需求，從而使用性能測試工具開發相應的性能測試腳本、開發相應的性能測試場景、在性能測試腳本中利用性能測試數據、在性能測試腳本中設置相應的思考時間、在性能測試場景中設置運行的參數等，以期能利用自動化的性能測試工具模擬現實中大量用戶同時訪問被測系統的情形。即，如果性能測試工具操作不當，將會導致無法準確的實現“模擬實際情況”的目標。例如，某些性能測試工程師在使用性能測試工具時不懂得利用“檢查點”這個功能，從而無法發現在性能測試執行過程中大量虛擬用戶甚至沒有登陸到系統中的嚴重問題，仍然認爲性能測試執行效果良好，被測系統性能沒有問題。

Web服務器和APP服務器
通俗的講，Web服務器傳送(serves)頁面使瀏覽器可以瀏覽，然而應用程序服務器提供的是客戶端應用程序可以調用(call)的方法(methods)。確切一點，你可以說：Web服務器專門處理HTTP請求(request)，但是應用程序服務器是通過很多協議來爲應用程序提供(serves)商業邏輯(business logic)。Web服務器(Web Server)Web服務器可以解析(handles)HTTP協議。當Web服務器接收到一個HTTP請求(request)，會返回一個HTTP響應(response)，例如送回一個HTML頁面。爲了處理一個請求(request)，Web服務器可以響應(response)一個靜態頁面或圖片，進行頁面跳轉(redirect)，或者把動態響應(dynamic response)的產生委託(delegate)給一些其它的程序例如CGI腳本，JSP(JavaServer Pages)腳本，servlets，ASP(Active Server Pages)腳本，服務器端(server-side)Javascrīpt，或者一些其它的服務器端(server-side)技術。無論它們(譯者注：腳本)的目的如何，這些服務器端(server-side)的程序通常產生一個HTML的響應(response)來讓瀏覽器可以瀏覽。要知道，Web服務器的代理模型(delegation model)非常簡單。當一個請求(request)被送到Web服務器裏來時，它只單純的把請求(request)傳遞給可以很好的處理請求(request)的程序(譯者注：服務器端腳本)。Web服務器僅僅提供一個可以執行服務器端(server-side)程序和返回(程序所產生的)響應(response)的環境，而不會超出職能範圍。服務器端(server-side)程序通常具有事務處理(transaction processing)，數據庫連接(database connectivity)和消息(messaging)等功能。雖然Web服務器不支持事務處理或數據庫連接池，但它可以配置(employ)各種策略(strategies)來實現容錯性(fault tolerance)和可擴展性(scalability)，例如負載平衡(load balancing)，緩衝(caching)。集羣特徵(clustering—features)經常被誤認爲僅僅是應用程序服務器專有的特徵。
應用程序服務器(The Application Server)根據我們的定義，作爲應用程序服務器，它通過各種協議，可以包括HTTP，把商業邏輯暴露給(expose)客戶端應用程序。Web服務器主要是處理向瀏覽器發送HTML以供瀏覽，而應用程序服務器提供訪問商業邏輯的途徑以供客戶端應用程序使用。應用程序使用此商業邏輯就象你調用對象的一個方法(或過程語言中的一個函數)一樣。應用程序服務器的客戶端(包含有圖形用戶界面(GUI)的)可能會運行在一臺PC、一個Web服務器或者甚至是其它的應用程序服務器上。在應用程序服務器與其客戶端之間來回穿梭(traveling)的信息不僅僅侷限於簡單的顯示標記。相反，這種信息就是程序邏輯(program logic)。 正是由於這種邏輯取得了(takes)數據和方法調用(calls)的形式而不是靜態HTML，所以客戶端纔可以隨心所欲的使用這種被暴露的商業邏輯。在大多數情形下，應用程序服務器是通過組件(component)的應用程序接口(API)把商業邏輯暴露(expose)(給客戶端應用程序)的，例如基於J2EE(Java 2 Platform, Enterprise Edition)應用程序服務器的EJB(Enterprise JavaBean)組件模型。此外，應用程序服務器可以管理自己的資源，例如看大門的工作(gate-keeping duties)包括安全(security)，事務處理(transaction processing)，資源池(resource pooling)， 和消息(messaging)。就象Web服務器一樣，應用程序服務器配置了多種可擴展(scalability)和容錯(fault tolerance)技術。 例如，設想一個在線商店(網站)提供實時定價(real-time pricing)和有效性(availability)信息。這個站點(site)很可能會提供一個表單(form)讓你來選擇產品。當你提交查詢(query)後，網站會進行查找(lookup)並把結果內嵌在HTML頁面中返回。網站可以有很多種方式來實現這種功能。我要介紹一個不使用應用程序服務器的情景和一個使用應用程序服務器的情景。觀察一下這兩中情景的不同會有助於你瞭解應用程序服務器的功能。
情景1：不帶應用程序服務器的Web服務器在此種情景下，一個Web服務器獨立提供在線商店的功能。Web服務器獲得你的請求(request)，然後發送給服務器端(server-side)可以處理請求(request)的程序。此程序從數據庫或文本文件(flat file，譯者注：flat file是指沒有特殊格式的非二進制的文件，如properties和XML文件等)中查找定價信息。一旦找到，服務器端(server-side)程序把結果信息表示成(formulate)HTML形式，最後Web服務器把會它發送到你的Web瀏覽器。簡而言之，Web服務器只是簡單的通過響應(response)HTML頁面來處理HTTP請求(request)。
情景2：帶應用程序服務器的Web服務器情景2和情景1相同的是Web服務器還是把響應(response)的產生委託(delegates)給腳本(譯者注：服務器端(server-side)程序)。然而，你可以把查找定價的商業邏輯(business logic)放到應用程序服務器上。由於這種變化，此腳本只是簡單的調用應用程序服務器的查找服務(lookup service)，而不是已經知道如何查找數據然後表示爲(formulate)一個響應(response)。 這時當該腳本程序產生HTML響應(response)時就可以使用該服務的返回結果了。在此情景中，應用程序服務器提供(serves)了用於查詢產品的定價信息的商業邏輯。(服務器的)這種功能(functionality)沒有指出有關顯示和客戶端如何使用此信息的細節，相反客戶端和應用程序服務器只是來回傳送數據。當有客戶端調用應用程序服務器的查找服務(lookup service)時，此服務只是簡單的查找並返回結果給客戶端。通過從響應產生(response-generating)HTML的代碼中分離出來，在應用程序之中該定價(查找)邏輯的可重用性更強了。其他的客戶端，例如收款機，也可以調用同樣的服務(service)來作爲一個店員給客戶結帳。相反，在情景1中的定價查找服務是不可重用的因爲信息內嵌在HTML頁中了。總而言之，在情景2的模型中，在Web服務器通過迴應HTML頁面來處理HTTP請求(request)，而應用程序服務器則是通過處理定價和有效性(availability)請求(request)來提供應用程序邏輯的。
警告(Caveats)現在，XML Web Services已經使應用程序服務器和Web服務器的界線混淆了。通過傳送一個XML有效載荷(payload)給服務器，Web服務器現在可以處理數據和響應(response)的能力與以前的應用程序服務器同樣多了。另外，現在大多數應用程序服務器也包含了Web服務器，這就意味着可以把Web服務器當作是應用程序服務器的一個子集(subset)。雖然應用程序服務器包含了Web服務器的功能，但是開發者很少把應用程序服務器部署(deploy)成這種功能(capacity)(譯者注：這種功能是指既有應用程序服務器的功能又有Web服務器的功能)。相反，如果需要，他們通常會把Web服務器獨立配置，和應用程序服務器一前一後。這種功能的分離有助於提高性能(簡單的Web請求(request)就不會影響應用程序服務器了)，分開配置(專門的Web服務器，集羣(clustering)等等)，而且給最佳產品的選取留有餘地。

性能瓶頸
性能瓶頸實際上就是一個軟件的性能缺陷，最通俗的理解“性能瓶頸”。
（1）硬件上的性能瓶頸主要指的是CPU、RAM方面的問題。例如，在進行軟件需求分析、概要設計時，確定了在數據庫服務器上需要6個CPU、 12G內存，但是在測試時，發現CPU的持續利用率超過95%，這時可以認爲在硬件上出現了性能瓶頸。
（2）應用軟件上的性能瓶頸一般指的是應用服務器、WEB服務器等應用軟件，還包括數據庫系統。例如，在WEBLogic平臺上配置了JDBC連接池的參數，最大連接數爲50，最小連接數爲5，增加量爲10。在測試時發現，當負載增加時，現有的連接數不足，系統會動態生成10個新的連接數，這樣導致了交易處理的響應時間大大的增加。這時可以認爲在應用軟件上出現了性能瓶頸。
（3）應用程序上的性能瓶頸，一般指的是開發人員新開發出來的應用程序。例如，用Java或者C開發出來的部署在應用服務器上用於用戶交易請求處理的應用程序。例如，某個開發員開發了一個繳費處理程序，在測試時發現，這個繳費處理程序在處理用戶發過來的併發繳費請求時，只能串行處理，無法並行處理，導致繳費交易的處理響應時間非常長，這時可以認爲在應用程序上出現了性能瓶頸。
（4）操作系統上的性能瓶頸，一般指的是Windows、Unix、Linux這些操作系統。例如，在windows系統中，虛擬內存設置的不合理，都指定爲C驅提供虛擬內存，在測試時發現當出現物理內存不足時，虛擬內存的交換效果非常不理想，導致交易的響應時間大大增加。這時可以認爲在操作系統上出現了性能瓶頸。
（5）網絡設備上的性能瓶頸，一般指的是防火牆、動態負載均衡器、交換機等設備。例如，在動態負載均衡器上設置了動態分發負載的機制，當發現某個應用服務器上的硬件資源已經到達極限時，動態負載均衡器將後續的交易請求發送到其它負載較輕的應用服務器上。在測試時發現，動態負載均衡機制沒有起到相應的作用，這時可以認爲在網絡設備上出現了性能瓶頸