一．系統吞度量要素：

一個系統的吞度量（承壓能力）與request對CPU的消耗、外部接口、IO等等緊密關聯。

單個reqeust 對CPU消耗越高，外部系統接口、IO影響速度越慢，系統吞吐能力越低，反之越高。

系統吞吐量幾個重要參數：QPS（TPS）、並發數、響應時間

QPS（TPS）：每秒鐘request/事務 數量

並發數： 系統同時處理的request/事務數

響應時間： 一般取平均響應時間

（很多人經常會把並發數和TPS理解混淆）

理解了上面三個要素的意義之後，就能推算出它們之間的關系：

QPS（TPS）= 並發數/平均響應時間

一個系統吞吐量通常由QPS（TPS）、並發數兩個因素決定，每套系統這兩個值都有一個相對極限值，在應用場景訪問壓力下，只要某一項達到系統最高值，系統的吞吐量就上不去了，如果壓力繼續增大，系統的吞吐量反而會下降，原因是系統超負荷工作，上下文切換、內存等等其它消耗導致系統性能下降。

決定系統響應時間要素

我們做項目要排計劃，可以多人同時並發做多項任務，也可以一個人或者多個人串行工作，始終會有一條關鍵路徑，這條路徑就是項目的工期。

系統一次調用的響應時間跟項目計劃一樣，也有一條關鍵路徑，這個關鍵路徑是就是系統影響時間；

關鍵路徑是有CPU運算、IO、外部系統響應等等組成。

二．系統吞吐量評估：

我們在做系統設計的時候就需要考慮CPU運算、IO、外部系統響應因素造成的影響以及對系統性能的初步預估。

而通常境況下，我們面對需求，我們評估出來的出來QPS、並發數之外，還有另外一個維度：日PV。

通過觀察系統的訪問日誌發現，在用戶量很大的情況下，各個時間周期內的同一時間段的訪問流量幾乎一樣。比如工作日的每天早上。只要能拿到日流量圖和QPS我們就可以推算日流量。

通常的技術方法：

1. 找出系統的最高TPS和日PV，這兩個要素有相對比較穩定的關系（除了放假、季節性因素影響之外）

2. 通過壓力測試或者經驗預估，得出最高TPS，然後跟進1的關系，計算出系統最高的日吞吐量。B2B中文和淘寶面對的客戶群不一樣，這兩個客戶群的網絡行為不應用，他們之間的TPS和PV關系比例也不一樣。

淘寶流量圖：

淘寶的TPS和PV之間的關系通常為 最高TPS：PV大約為 1 : 11*3600 （相當於按最高TPS訪問11個小時，這個是商品詳情的場景，不同的應用場景會有一些不同）

B) B2B中文站

B2B的TPS和PV之間的關系不同的系統不同的應用場景比例變化比較大，粗略估計在1 : 8個小時左右的關系（09年對offerdetail的流量分析數據）。旺鋪和offerdetail這兩個比例相差很大，可能是因為爬蟲暫的比例較高的原因導致。

在淘寶環境下，假設我們壓力測試出的TPS為100，那麽這個系統的日吞吐量=100*11*3600=396萬

這個是在簡單（單一url）的情況下，有些頁面，一個頁面有多個request，系統的實際吞吐量還要小。

無論有無思考時間（T_think），測試所得的TPS值和並發虛擬用戶數(U_concurrent)、Loadrunner讀取的交易響應時間（T_response）之間有以下關系（穩定運行情況下）：
TPS=U_concurrent / (T_response+T_think)。

並發數、QPS、平均響應時間三者之間關系

來源：http://www.cnblogs.com/jackei/

軟件性能測試的基本概念和計算公式

一、軟件性能的關註點

對一個軟件做性能測試時需要關註那些性能呢？

我們想想在軟件設計、部署、使用、維護中一共有哪些角色的參與，然後再考慮這些角色各自關註的性能點是什麽，作為一個軟件性能測試工程師，我們又該關註什麽？

首先，開發軟件的目的是為了讓用戶使用，我們先站在用戶的角度分析一下，用戶需要關註哪些性能。

對於用戶來說，當點擊一個按鈕、鏈接或發出一條指令開始，到系統把結果已用戶感知的形式展現出來為止，這個過程所消耗的時間是用戶對這個軟件性能的直觀印象。也就是我們所說的響應時間，當相應時間較小時，用戶體驗是很好的，當然用戶體驗的響應時間包括個人主觀因素和客觀響應時間，在設計軟件時，我們就需要考慮到如何更好地結合這兩部分達到用戶最佳的體驗。如：用戶在大數據量查詢時，我們可以將先提取出來的數據展示給用戶，在用戶看的過程中繼續進行數據檢索，這時用戶並不知道我們後臺在做什麽。

用戶關註的是用戶操作的相應時間。

其次，我們站在管理員的角度考慮需要關註的性能點。

1、 相應時間
2、 服務器資源使用情況是否合理
3、 應用服務器和數據庫資源使用是否合理
4、 系統能否實現擴展
5、 系統最多支持多少用戶訪問、系統最大業務處理量是多少
6、 系統性能可能存在的瓶頸在哪裏
7、 更換那些設備可以提高性能
8、 系統能否支持7×24小時的業務訪問

再次，站在開發（設計）人員角度去考慮。

1、 架構設計是否合理
2、 數據庫設計是否合理
3、 代碼是否存在性能方面的問題
4、 系統中是否有不合理的內存使用方式
5、 系統中是否存在不合理的線程同步方式
6、 系統中是否存在不合理的資源競爭

那麽站在性能測試工程師的角度，我們要關註什麽呢？

一句話，我們要關註以上所有的性能點。

二、軟件性能的幾個主要術語

1、響應時間：對請求作出響應所需要的時間

網絡傳輸時間：N1+N2+N3+N4

應用服務器處理時間：A1+A3

數據庫服務器處理時間：A2

響應時間=N1+N2+N3+N4+A1+A3+A2

2、並發用戶數的計算公式

系統用戶數：系統額定的用戶數量，如一個OA系統，可能使用該系統的用戶總數是5000個，那麽這個數量，就是系統用戶數。

同時在線用戶數：在一定的時間範圍內，最大的同時在線用戶數量。
同時在線用戶數=每秒請求數RPS（吞吐量）+並發連接數+平均用戶思考時間

平均並發用戶數的計算：C=nL / T

其中C是平均的並發用戶數，n是平均每天訪問用戶數（login session），L是一天內用戶從登錄到退出的平均時間（login session的平均時間），T是考察時間長度（一天內多長時間有用戶使用系統）

並發用戶數峰值計算：C^約等於C + 3*根號C

其中C^是並發用戶峰值，C是平均並發用戶數，該公式遵循泊松分布理論。

3、吞吐量的計算公式

指單位時間內系統處理用戶的請求數

從業務角度看，吞吐量可以用：請求數/秒、頁面數/秒、人數/天或處理業務數/小時等單位來衡量

從網絡角度看，吞吐量可以用：字節/秒來衡量

對於交互式應用來說，吞吐量指標反映的是服務器承受的壓力，他能夠說明系統的負載能力

以不同方式表達的吞吐量可以說明不同層次的問題，例如，以字節數/秒方式可以表示數要受網絡基礎設施、服務器架構、應用服務器制約等方面的瓶頸；已請求數/秒的方式表示主要是受應用服務器和應用代碼的制約體現出的瓶頸。

當沒有遇到性能瓶頸的時候，吞吐量與虛擬用戶數之間存在一定的聯系，可以采用以下公式計算：F=VU * R /

其中F為吞吐量，VU表示虛擬用戶個數，R表示每個虛擬用戶發出的請求數，T表示性能測試所用的時間

4、性能計數器

是描述服務器或操作系統性能的一些數據指標，如使用內存數、進程時間，在性能測試中發揮著“監控和分析”的作用，尤其是在分析統統可擴展性、進行新能瓶頸定位時有著非常關鍵的作用。

資源利用率：指系統各種資源的使用情況，如cpu占用率為68%，內存占用率為55%，一般使用“資源實際使用/總的資源可用量”形成資源利用率。

5、思考時間的計算公式

Think Time，從業務角度來看，這個時間指用戶進行操作時每個請求之間的時間間隔，而在做新能測試時，為了模擬這樣的時間間隔，引入了思考時間這個概念，來更加真實的模擬用戶的操作。

在吞吐量這個公式中F=VU * R / T說明吞吐量F是VU數量、每個用戶發出的請求數R和時間T的函數，而其中的R又可以用時間T和用戶思考時間TS來計算：R = T / TS

下面給出一個計算思考時間的一般步驟：

A、首先計算出系統的並發用戶數

C=nL / T F=R×C

B、統計出系統平均的吞吐量

F=VU * R / T R×C = VU * R / T

C、統計出平均每個用戶發出的請求數量

R=u*C*T/VU

D、根據公式計算出思考時間

TS=T/R

######################################################

吞吐量/處理能力
處理能力又叫吞吐量，指的是單位時間內處理的客戶端請求數量。通常情況下，吞吐量用請求數/秒 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)JavaScript，或者一些其它的服務器端(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）網絡設備上的性能瓶頸，一般指的是防火墻、動態負載均衡器、交換機等設備。例如，在動態負載均衡器上設置了動態分發負載的機制，當發現某個應用服務器上的硬件資源已經到達極限時，動態負載均衡器將後續的交易請求發送到其它負載較輕的應用服務器上。在測試時發現，動態負載均衡機制沒有起到相應的作用，這時可以認為在網絡設備上出現了性能瓶頸。

系統吞吐量（TPS）、用戶並發量、性能測試概念和公式