https://wenku.baidu.com/view/c8429d3978563c1ec5da50e2524de518974bd37d.html

https://blog.csdn.net/adparking/article/details/37583965

一．系統(tǒng)吞度量要素：

??一個系統(tǒng)的吞度量（承壓能力）與request對CPU的消耗、外部接口、IO等等緊密關(guān)聯(lián)。

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

系統(tǒng)吞吐量幾個重要參數(shù)：QPS（TPS）、并發(fā)數(shù)、響應(yīng)時間

QPS（TPS）：每秒鐘request/事務(wù)?數(shù)量

并發(fā)數(shù)：系統(tǒng)同時處理的request/事務(wù)數(shù)

響應(yīng)時間：?一般取平均響應(yīng)時間

（很多人經(jīng)常會把并發(fā)數(shù)和TPS理解混淆）

理解了上面三個要素的意義之后，就能推算出它們之間的關(guān)系：

QPS（TPS）=?并發(fā)數(shù)/平均響應(yīng)時間

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

決定系統(tǒng)響應(yīng)時間要素

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

系統(tǒng)一次調(diào)用的響應(yīng)時間跟項目計劃一樣，也有一條關(guān)鍵路徑，這個關(guān)鍵路徑是就是系統(tǒng)影響時間；

關(guān)鍵路徑是有CPU運算、IO、外部系統(tǒng)響應(yīng)等等組成。

二．系統(tǒng)吞吐量評估：

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

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

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

通常的技術(shù)方法：

????????1.?找出系統(tǒng)的最高TPS和日PV，這兩個要素有相對比較穩(wěn)定的關(guān)系（除了放假、季節(jié)性因素影響之外）

2.?通過壓力測試或者經(jīng)驗預(yù)估，得出最高TPS，然后跟進1的關(guān)系，計算出系統(tǒng)最高的日吞吐量。B2B中文和淘寶面對的客戶群不一樣，這兩個客戶群的網(wǎng)絡(luò)行為不應(yīng)用，他們之間的TPS和PV關(guān)系比例也不一樣。

A)淘寶

淘寶流量圖：

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

B) B2B中文站

B2B的TPS和PV之間的關(guān)系不同的系統(tǒng)不同的應(yīng)用場景比例變化比較大，粗略估計在1 : 8個小時左右的關(guān)系（09年對offerdetail的流量分析數(shù)據(jù)）。旺鋪和offerdetail這兩個比例相差很大，可能是因為爬蟲暫的比例較高的原因?qū)е隆?/p>

在淘寶環(huán)境下，假設(shè)我們壓力測試出的TPS為100，那么這個系統(tǒng)的日吞吐量=100*11*3600=396萬

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

無論有無思考時間（T_think），測試所得的TPS值和并發(fā)虛擬用戶數(shù)(U_concurrent)、Loadrunner讀取的交易響應(yīng)時間（T_response）之間有以下關(guān)系（穩(wěn)定運行情況下）：

TPS=U_concurrent / (T_response+T_think)。

并發(fā)數(shù)、QPS、平均響應(yīng)時間三者之間關(guān)系

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

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

一、軟件性能的關(guān)注點

對一個軟件做性能測試時需要關(guān)注那些性能呢？

我們想想在軟件設(shè)計、部署、使用、維護中一共有哪些角色的參與，然后再考慮這些角色各自關(guān)注的性能點是什么，作為一個軟件性能測試工程師，我們又該關(guān)注什么？

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

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

用戶關(guān)注的是用戶操作的相應(yīng)時間。

其次，我們站在管理員的角度考慮需要關(guān)注的性能點。

1、 相應(yīng)時間

2、 服務(wù)器資源使用情況是否合理

3、 應(yīng)用服務(wù)器和數(shù)據(jù)庫資源使用是否合理

4、 系統(tǒng)能否實現(xiàn)擴展

5、 系統(tǒng)最多支持多少用戶訪問、系統(tǒng)最大業(yè)務(wù)處理量是多少

6、 系統(tǒng)性能可能存在的瓶頸在哪里

7、 更換那些設(shè)備可以提高性能

8、 系統(tǒng)能否支持7×24小時的業(yè)務(wù)訪問

再次，站在開發(fā)（設(shè)計）人員角度去考慮。

1、 架構(gòu)設(shè)計是否合理

2、 數(shù)據(jù)庫設(shè)計是否合理

3、 代碼是否存在性能方面的問題

4、 系統(tǒng)中是否有不合理的內(nèi)存使用方式

5、 系統(tǒng)中是否存在不合理的線程同步方式

6、 系統(tǒng)中是否存在不合理的資源競爭

那么站在性能測試工程師的角度，我們要關(guān)注什么呢？

一句話，我們要關(guān)注以上所有的性能點。

二、軟件性能的幾個主要術(shù)語

1、響應(yīng)時間：對請求作出響應(yīng)所需要的時間

網(wǎng)絡(luò)傳輸時間：N1+N2+N3+N4

應(yīng)用服務(wù)器處理時間：A1+A3

數(shù)據(jù)庫服務(wù)器處理時間：A2

響應(yīng)時間=N1+N2+N3+N4+A1+A3+A2

2、并發(fā)用戶數(shù)的計算公式

系統(tǒng)用戶數(shù)：系統(tǒng)額定的用戶數(shù)量，如一個OA系統(tǒng)，可能使用該系統(tǒng)的用戶總數(shù)是5000個，那么這個數(shù)量，就是系統(tǒng)用戶數(shù)。

同時在線用戶數(shù)：在一定的時間范圍內(nèi)，最大的同時在線用戶數(shù)量。

同時在線用戶數(shù)=每秒請求數(shù)RPS（吞吐量）+并發(fā)連接數(shù)+平均用戶思考時間

平均并發(fā)用戶數(shù)的計算：C=nL / T

其中C是平均的并發(fā)用戶數(shù)，n是平均每天訪問用戶數(shù)（login session），L是一天內(nèi)用戶從登錄到退出的平均時間（login session的平均時間），T是考察時間長度（一天內(nèi)多長時間有用戶使用系統(tǒng)）

并發(fā)用戶數(shù)峰值計算：C^約等于C + 3*根號C

其中C^是并發(fā)用戶峰值，C是平均并發(fā)用戶數(shù)，該公式遵循泊松分布理論。

3、吞吐量的計算公式

指單位時間內(nèi)系統(tǒng)處理用戶的請求數(shù)

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

從網(wǎng)絡(luò)角度看，吞吐量可以用：字節(jié)/秒來衡量

對于交互式應(yīng)用來說，吞吐量指標反映的是服務(wù)器承受的壓力，他能夠說明系統(tǒng)的負載能力

以不同方式表達的吞吐量可以說明不同層次的問題，例如，以字節(jié)數(shù)/秒方式可以表示數(shù)要受網(wǎng)絡(luò)基礎(chǔ)設(shè)施、服務(wù)器架構(gòu)、應(yīng)用服務(wù)器制約等方面的瓶頸；已請求數(shù)/秒的方式表示主要是受應(yīng)用服務(wù)器和應(yīng)用代碼的制約體現(xiàn)出的瓶頸。

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

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

4、性能計數(shù)器

是描述服務(wù)器或操作系統(tǒng)性能的一些數(shù)據(jù)指標，如使用內(nèi)存數(shù)、進程時間，在性能測試中發(fā)揮著“監(jiān)控和分析”的作用，尤其是在分析統(tǒng)統(tǒng)可擴展性、進行新能瓶頸定位時有著非常關(guān)鍵的作用。

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

5、思考時間的計算公式

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

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

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

A、首先計算出系統(tǒng)的并發(fā)用戶數(shù)

C=nL / T F=R×C

B、統(tǒng)計出系統(tǒng)平均的吞吐量

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

C、統(tǒng)計出平均每個用戶發(fā)出的請求數(shù)量

R=u*C*T/VU

D、根據(jù)公式計算出思考時間

TS=T/R

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

吞吐量/處理能力

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

負載

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

響應(yīng)時間

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

同時在線用戶

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

超級并發(fā)用戶

對于一個網(wǎng)站來講,可能存在WEB服務(wù)器、應(yīng)用服務(wù)器、數(shù)據(jù)庫服務(wù)器三個層次，而用戶所使用的瀏覽器是在最外面的客戶端層面。如果某個時間點或時間段內(nèi)，共有1000個用戶同時在線，他們進行著各種各樣的操作，而某個時間點上可能存在10個左右的用戶同時進行了一個或多個操作，導(dǎo)致WEB服務(wù)器同時接收到了10個左右的交易請求，我們稱這個10個左右的用戶為超級并發(fā)用戶。當進行性能測試時，如果你使用的是超級并發(fā)用戶，則可以稱之為超級并發(fā)負載。

性能測試腳本

腳本是用負載模擬工具開發(fā)出來的。腳本是一些代碼的組合體，它用代碼來實現(xiàn)用戶對應(yīng)用系統(tǒng)的操作。例如,你在一個網(wǎng)站上訪問首頁、輸入用戶名和密碼后點擊登錄按鈕進行登錄，這是用戶對應(yīng)用系統(tǒng)的兩步操作內(nèi)容，在腳本中則包含了實現(xiàn)這兩個操作步驟的代碼。如果你要模擬10000個用戶的負載，這10000個用戶中50%進行首頁的訪問、20%進行注冊、20%進行查詢、10%進行某個頁面的瀏覽，則你需要制作5個腳本，分別是首頁訪問腳本、注冊腳本、查詢腳本、頁面瀏覽腳本。

事務(wù)?

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

交易

交易分為業(yè)務(wù)層面和技術(shù)層面兩種定義。業(yè)務(wù)層面交易是指完成一次完整的業(yè)務(wù)操作，例如進行一次取款、查詢操作。技術(shù)層面的交易是指進行一次應(yīng)用程序至應(yīng)用程序、或者應(yīng)用程序至數(shù)據(jù)庫的系統(tǒng)操作。一般的一筆業(yè)務(wù)交易由多筆技術(shù)交易組成，根據(jù)業(yè)務(wù)交易的復(fù)雜度和系統(tǒng)應(yīng)用架構(gòu)的不同，其比例大致為1：2-1：10。

TPS與HPS

TPS (Transactions Per Second)是估算應(yīng)用系統(tǒng)性能的重要依據(jù)。其意義是應(yīng)用系統(tǒng)每秒鐘處理完成的交易數(shù)量，尤其是交易類系統(tǒng)。一般的，評價系統(tǒng)性能均以每秒鐘完成的技術(shù)交易的數(shù)量來衡量。系統(tǒng)整體處理能力取決于處理能力最低模塊的TPS值。依據(jù)經(jīng)驗，應(yīng)用系統(tǒng)的處理能力一般要求在10-100左右。不同應(yīng)用系統(tǒng)的TPS有著十分大的差別，一般需要通過性能測試進行準確估算。當系統(tǒng)沒有達到性能瓶頸時，TPS隨著負載的增加呈近似線性增長，當接近性能瓶頸時出現(xiàn)拐點；如果系統(tǒng)健壯性較好，在到達性能瓶頸后，TPS基本保持水平，不會再隨著負載的增加而有顯著增長；而如果系統(tǒng)存在比較嚴重的性能問題，當?shù)竭_性能瓶頸后，TPS會出現(xiàn)明顯的下降趨勢。HPS：(Hits per Second)每秒點擊次數(shù)，是指在一秒鐘的時間內(nèi)用戶對Web頁面的鏈接、提交按鈕等點擊總和它一般和TPS成正比關(guān)系，是B/S系統(tǒng)中非常重要的性能指標之一。

TPS可以有多種衡量單位，在進行性能測試的業(yè)務(wù)模型分析時使用，例如：

（1）在稅務(wù)系統(tǒng)中，可以用“系統(tǒng)每個月要處理10萬用戶的業(yè)務(wù)操作”，這里的TPS用企業(yè)數(shù)/月來衡量；（2）在稅務(wù)系統(tǒng)中，也可以用“系統(tǒng)在第七天的8個小時內(nèi)要處理4萬用戶的業(yè)務(wù)操作”，這里的TPS用企業(yè)數(shù)/天來衡量；（3）在稅務(wù)系統(tǒng)中，也可以用“系統(tǒng)在第七天的10點到11點之間要處理1.2萬用戶的3種繳稅交易操作，即3.6萬次繳稅交易操作”，這里的TPS用交易數(shù)/小時來衡量；（4）在稅務(wù)系統(tǒng)中，也可以用“系統(tǒng)在第七天的10點到11點之間要處理1.2萬用戶的3種繳稅交易操作，即3.6萬次繳稅交易操作，每次繳稅交易要從客戶端向服務(wù)器發(fā)送平均10次HTTP請求，即36萬次HTTP請求操作”，這里的TPS用請求數(shù)/小時來衡量。

HPS是用來衡量很多用戶使用客戶端進行操作，向服務(wù)器發(fā)送請求的效率。我們認為HPS表現(xiàn)的是最終用戶的整體行為，是衡量在線負載程度的一個指標。而TPS表現(xiàn)的是服務(wù)器端的程序行為，是衡量服務(wù)器處理能力高低的一個主要指標。

例如：HPS＝“點擊次數(shù)/秒”；TPS＝“處理事務(wù)數(shù)/秒”，HPS與TPS沒有絕對的關(guān)系。

性能測試實現(xiàn)的準確性

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

Web服務(wù)器和APP服務(wù)器

通俗的講，Web服務(wù)器傳送(serves)頁面使瀏覽器可以瀏覽，然而應(yīng)用程序服務(wù)器提供的是客戶端應(yīng)用程序可以調(diào)用(call)的方法(methods)。確切一點，你可以說：Web服務(wù)器專門處理HTTP請求(request)，但是應(yīng)用程序服務(wù)器是通過很多協(xié)議來為應(yīng)用程序提供(serves)商業(yè)邏輯(business logic)。Web服務(wù)器(Web Server)Web服務(wù)器可以解析(handles)HTTP協(xié)議。當Web服務(wù)器接收到一個HTTP請求(request)，會返回一個HTTP響應(yīng)(response)，例如送回一個HTML頁面。為了處理一個請求(request)，Web服務(wù)器可以響應(yīng)(response)一個靜態(tài)頁面或圖片，進行頁面跳轉(zhuǎn)(redirect)，或者把動態(tài)響應(yīng)(dynamic response)的產(chǎn)生委托(delegate)給一些其它的程序例如CGI腳本，JSP(JavaServer Pages)腳本，servlets，ASP(Active Server Pages)腳本，服務(wù)器端(server-side)JavaScript，或者一些其它的服務(wù)器端(server-side)技術(shù)。無論它們(譯者注：腳本)的目的如何，這些服務(wù)器端(server-side)的程序通常產(chǎn)生一個HTML的響應(yīng)(response)來讓瀏覽器可以瀏覽。要知道，Web服務(wù)器的代理模型(delegation model)非常簡單。當一個請求(request)被送到Web服務(wù)器里來時，它只單純的把請求(request)傳遞給可以很好的處理請求(request)的程序(譯者注：服務(wù)器端腳本)。Web服務(wù)器僅僅提供一個可以執(zhí)行服務(wù)器端(server-side)程序和返回(程序所產(chǎn)生的)響應(yīng)(response)的環(huán)境，而不會超出職能范圍。服務(wù)器端(server-side)程序通常具有事務(wù)處理(transaction processing)，數(shù)據(jù)庫連接(database connectivity)和消息(messaging)等功能。雖然Web服務(wù)器不支持事務(wù)處理或數(shù)據(jù)庫連接池，但它可以配置(employ)各種策略(strategies)來實現(xiàn)容錯性(fault tolerance)和可擴展性(scalability)，例如負載平衡(load balancing)，緩沖(caching)。集群特征(clustering—features)經(jīng)常被誤認為僅僅是應(yīng)用程序服務(wù)器專有的特征。?

應(yīng)用程序服務(wù)器(The Application Server)根據(jù)我們的定義，作為應(yīng)用程序服務(wù)器，它通過各種協(xié)議，可以包括HTTP，把商業(yè)邏輯暴露給(expose)客戶端應(yīng)用程序。Web服務(wù)器主要是處理向瀏覽器發(fā)送HTML以供瀏覽，而應(yīng)用程序服務(wù)器提供訪問商業(yè)邏輯的途徑以供客戶端應(yīng)用程序使用。應(yīng)用程序使用此商業(yè)邏輯就象你調(diào)用對象的一個方法(或過程語言中的一個函數(shù))一樣。應(yīng)用程序服務(wù)器的客戶端(包含有圖形用戶界面(GUI)的)可能會運行在一臺PC、一個Web服務(wù)器或者甚至是其它的應(yīng)用程序服務(wù)器上。在應(yīng)用程序服務(wù)器與其客戶端之間來回穿梭(traveling)的信息不僅僅局限于簡單的顯示標記。相反，這種信息就是程序邏輯(program logic)。 正是由于這種邏輯取得了(takes)數(shù)據(jù)和方法調(diào)用(calls)的形式而不是靜態(tài)HTML，所以客戶端才可以隨心所欲的使用這種被暴露的商業(yè)邏輯。在大多數(shù)情形下，應(yīng)用程序服務(wù)器是通過組件(component)的應(yīng)用程序接口(API)把商業(yè)邏輯暴露(expose)(給客戶端應(yīng)用程序)的，例如基于J2EE(Java 2 Platform, Enterprise Edition)應(yīng)用程序服務(wù)器的EJB(Enterprise JavaBean)組件模型。此外，應(yīng)用程序服務(wù)器可以管理自己的資源，例如看大門的工作(gate-keeping duties)包括安全(security)，事務(wù)處理(transaction processing)，資源池(resource pooling)， 和消息(messaging)。就象Web服務(wù)器一樣，應(yīng)用程序服務(wù)器配置了多種可擴展(scalability)和容錯(fault tolerance)技術(shù)。 例如，設(shè)想一個在線商店(網(wǎng)站)提供實時定價(real-time pricing)和有效性(availability)信息。這個站點(site)很可能會提供一個表單(form)讓你來選擇產(chǎn)品。當你提交查詢(query)后，網(wǎng)站會進行查找(lookup)并把結(jié)果內(nèi)嵌在HTML頁面中返回。網(wǎng)站可以有很多種方式來實現(xiàn)這種功能。我要介紹一個不使用應(yīng)用程序服務(wù)器的情景和一個使用應(yīng)用程序服務(wù)器的情景。觀察一下這兩中情景的不同會有助于你了解應(yīng)用程序服務(wù)器的功能。

情景1：不帶應(yīng)用程序服務(wù)器的Web服務(wù)器在此種情景下，一個Web服務(wù)器獨立提供在線商店的功能。Web服務(wù)器獲得你的請求(request)，然后發(fā)送給服務(wù)器端(server-side)可以處理請求(request)的程序。此程序從數(shù)據(jù)庫或文本文件(flat file，譯者注：flat file是指沒有特殊格式的非二進制的文件，如properties和XML文件等)中查找定價信息。一旦找到，服務(wù)器端(server-side)程序把結(jié)果信息表示成(formulate)HTML形式，最后Web服務(wù)器把會它發(fā)送到你的Web瀏覽器。簡而言之，Web服務(wù)器只是簡單的通過響應(yīng)(response)HTML頁面來處理HTTP請求(request)。?

情景2：帶應(yīng)用程序服務(wù)器的Web服務(wù)器情景2和情景1相同的是Web服務(wù)器還是把響應(yīng)(response)的產(chǎn)生委托(delegates)給腳本(譯者注：服務(wù)器端(server-side)程序)。然而，你可以把查找定價的商業(yè)邏輯(business logic)放到應(yīng)用程序服務(wù)器上。由于這種變化，此腳本只是簡單的調(diào)用應(yīng)用程序服務(wù)器的查找服務(wù)(lookup service)，而不是已經(jīng)知道如何查找數(shù)據(jù)然后表示為(formulate)一個響應(yīng)(response)。 這時當該腳本程序產(chǎn)生HTML響應(yīng)(response)時就可以使用該服務(wù)的返回結(jié)果了。在此情景中，應(yīng)用程序服務(wù)器提供(serves)了用于查詢產(chǎn)品的定價信息的商業(yè)邏輯。(服務(wù)器的)這種功能(functionality)沒有指出有關(guān)顯示和客戶端如何使用此信息的細節(jié)，相反客戶端和應(yīng)用程序服務(wù)器只是來回傳送數(shù)據(jù)。當有客戶端調(diào)用應(yīng)用程序服務(wù)器的查找服務(wù)(lookup service)時，此服務(wù)只是簡單的查找并返回結(jié)果給客戶端。通過從響應(yīng)產(chǎn)生(response-generating)HTML的代碼中分離出來，在應(yīng)用程序之中該定價(查找)邏輯的可重用性更強了。其他的客戶端，例如收款機，也可以調(diào)用同樣的服務(wù)(service)來作為一個店員給客戶結(jié)帳。相反，在情景1中的定價查找服務(wù)是不可重用的因為信息內(nèi)嵌在HTML頁中了。總而言之，在情景2的模型中，在Web服務(wù)器通過回應(yīng)HTML頁面來處理HTTP請求(request)，而應(yīng)用程序服務(wù)器則是通過處理定價和有效性(availability)請求(request)來提供應(yīng)用程序邏輯的。

警告(Caveats) 現(xiàn)在，XML Web Services已經(jīng)使應(yīng)用程序服務(wù)器和Web服務(wù)器的界線混淆了。通過傳送一個XML有效載荷(payload)給服務(wù)器，Web服務(wù)器現(xiàn)在可以處理數(shù)據(jù)和響應(yīng)(response)的能力與以前的應(yīng)用程序服務(wù)器同樣多了。另外，現(xiàn)在大多數(shù)應(yīng)用程序服務(wù)器也包含了Web服務(wù)器，這就意味著可以把Web服務(wù)器當作是應(yīng)用程序服務(wù)器的一個子集(subset)。雖然應(yīng)用程序服務(wù)器包含了Web服務(wù)器的功能，但是開發(fā)者很少把應(yīng)用程序服務(wù)器部署(deploy)成這種功能(capacity)(譯者注：這種功能是指既有應(yīng)用程序服務(wù)器的功能又有Web服務(wù)器的功能)。相反，如果需要，他們通常會把Web服務(wù)器獨立配置，和應(yīng)用程序服務(wù)器一前一后。這種功能的分離有助于提高性能(簡單的Web請求(request)就不會影響應(yīng)用程序服務(wù)器了)，分開配置(專門的Web服務(wù)器，集群(clustering)等等)，而且給最佳產(chǎn)品的選取留有余地。

性能瓶頸

性能瓶頸實際上就是一個軟件的性能缺陷，最通俗的理解“性能瓶頸”。

（1）硬件上的性能瓶頸主要指的是CPU、RAM方面的問題。例如，在進行軟件需求分析、概要設(shè)計時，確定了在數(shù)據(jù)庫服務(wù)器上需要6個CPU、12G內(nèi)存，但是在測試時，發(fā)現(xiàn)CPU的持續(xù)利用率超過95%，這時可以認為在硬件上出現(xiàn)了性能瓶頸。

（2）應(yīng)用軟件上的性能瓶頸一般指的是應(yīng)用服務(wù)器、WEB服務(wù)器等應(yīng)用軟件，還包括數(shù)據(jù)庫系統(tǒng)。例如，在WEBLogic平臺上配置了JDBC連接池的參數(shù)，最大連接數(shù)為50，最小連接數(shù)為5，增加量為10。在測試時發(fā)現(xiàn)，當負載增加時，現(xiàn)有的連接數(shù)不足，系統(tǒng)會動態(tài)生成10個新的連接數(shù)，這樣導(dǎo)致了交易處理的響應(yīng)時間大大的增加。這時可以認為在應(yīng)用軟件上出現(xiàn)了性能瓶頸。

（3）應(yīng)用程序上的性能瓶頸，一般指的是開發(fā)人員新開發(fā)出來的應(yīng)用程序。例如，用Java或者C開發(fā)出來的部署在應(yīng)用服務(wù)器上用于用戶交易請求處理的應(yīng)用程序。例如，某個開發(fā)員開發(fā)了一個繳費處理程序，在測試時發(fā)現(xiàn)，這個繳費處理程序在處理用戶發(fā)過來的并發(fā)繳費請求時，只能串行處理，無法并行處理，導(dǎo)致繳費交易的處理響應(yīng)時間非常長，這時可以認為在應(yīng)用程序上出現(xiàn)了性能瓶頸。

（4）操作系統(tǒng)上的性能瓶頸，一般指的是Windows、Unix、Linux這些操作系統(tǒng)。例如，在windows系統(tǒng)中，虛擬內(nèi)存設(shè)置的不合理，都指定為C驅(qū)提供虛擬內(nèi)存，在測試時發(fā)現(xiàn)當出現(xiàn)物理內(nèi)存不足時，虛擬內(nèi)存的交換效果非常不理想，導(dǎo)致交易的響應(yīng)時間大大增加。這時可以認為在操作系統(tǒng)上出現(xiàn)了性能瓶頸。

（5）網(wǎng)絡(luò)設(shè)備上的性能瓶頸，一般指的是防火墻、動態(tài)負載均衡器、交換機等設(shè)備。例如，在動態(tài)負載均衡器上設(shè)置了動態(tài)分發(fā)負載的機制，當發(fā)現(xiàn)某個應(yīng)用服務(wù)器上的硬件資源已經(jīng)到達極限時，動態(tài)負載均衡器將后續(xù)的交易請求發(fā)送到其它負載較輕的應(yīng)用服務(wù)器上。在測試時發(fā)現(xiàn)，動態(tài)負載均衡機制沒有起到相應(yīng)的作用，這時可以認為在網(wǎng)絡(luò)設(shè)備上出現(xiàn)了性能瓶頸