1. 具體問(wèn)題具體分析(這是由于不同的應(yīng)用系統(tǒng)，不同的測(cè)試目的，不同的性能關(guān)注點(diǎn))

2. 查找瓶頸時(shí)按以下順序，由易到難。

服務(wù)器硬件瓶頸 網(wǎng)絡(luò)瓶頸(對(duì)局域網(wǎng)，可以不考慮) 服務(wù)器操作系統(tǒng)瓶頸(參數(shù)配置) 中間件瓶頸(參數(shù)配置，數(shù)據(jù)庫(kù)，web服務(wù)器等) 應(yīng)用瓶頸(SQL語(yǔ)句、數(shù)據(jù)庫(kù)設(shè)計(jì)、業(yè)務(wù)邏輯、算法等)

分析的信息來(lái)源：

1. 根據(jù)場(chǎng)景運(yùn)行過(guò)程中的錯(cuò)誤提示信息

2. 根據(jù)測(cè)試結(jié)果收集到的監(jiān)控指標(biāo)數(shù)據(jù)

一.錯(cuò)誤提示分析

分析實(shí)例：

1.Error: Failed to connect to server “172.17.7.230″: [10060] Connection

Error: timed out Error: Server “172.17.7.230″ has shut down the connection prematurely

分析：

A、應(yīng)用服務(wù)死掉。

(小用戶時(shí)：程序上的問(wèn)題。程序上處理數(shù)據(jù)庫(kù)的問(wèn)題，實(shí)際測(cè)試中多半是服務(wù)器鏈接的配置問(wèn)題)

B、應(yīng)用服務(wù)沒(méi)有死

(應(yīng)用服務(wù)參數(shù)設(shè)置問(wèn)題)

對(duì)應(yīng)的Apache和tomcat的最大鏈接數(shù)需要修改，如果連接時(shí)收到connection refused消息，說(shuō)明應(yīng)提高相應(yīng)的服務(wù)器最大連接的設(shè)置，增加幅度要根據(jù)實(shí)際情況和服務(wù)器硬件的情況來(lái)定，建議每次增加25%!

C、數(shù)據(jù)庫(kù)的連接

(數(shù)據(jù)庫(kù)啟動(dòng)的最大連接數(shù)(跟硬件的內(nèi)存有關(guān)))

D、我們的應(yīng)用程序spring控制的最大鏈接數(shù)太低

2. Error: Page download timeout (120 seconds) has expired

分析：

A、應(yīng)用服務(wù)參數(shù)設(shè)置太大導(dǎo)致服務(wù)器的瓶頸

B、頁(yè)面中圖片太多

C、在程序處理表的時(shí)候檢查字段太大多

 D、實(shí)際測(cè)試時(shí)有些資源需要請(qǐng)求外網(wǎng)，而我們的測(cè)試環(huán)境是局域網(wǎng)環(huán)境

3. Error “http://172.17.7.230/Home.do....”

分析：

A、腳本設(shè)計(jì)錯(cuò)誤，造成頁(yè)面異常。服務(wù)器有響應(yīng)!

B、并發(fā)數(shù)過(guò)大，造成服務(wù)器響應(yīng)延遲。

4. Error page “text=xxxxx”

分析：

A、腳本設(shè)計(jì)問(wèn)題，例如，前一腳本修改了某些內(nèi)容，造成后面的腳本訪問(wèn)異常。

B、不確定因素，有時(shí)候回放正常的腳本，一放到場(chǎng)景中就出現(xiàn)這樣的錯(cuò)誤。只能反復(fù)修改腳本!

二.監(jiān)控指標(biāo)數(shù)據(jù)分析

1.Vusers數(shù)

Loadrunner 系統(tǒng)設(shè)置的虛擬用戶數(shù)目。Vuser去實(shí)際調(diào)用事先制作的腳本文件中的應(yīng)用。

每個(gè)Vuser產(chǎn)生響應(yīng)的操作，所有的操作對(duì)服務(wù)器形成并發(fā)。

顏色 比例 度量 圖最小值 圖平均值 圖最大值 圖中間值 圖SD

1 Run 0.0 21.25 44 41 21.276

 在實(shí)際測(cè)試中，Vusers可以根據(jù)實(shí)際情況的需要，在測(cè)試過(guò)程中增加或者減少。

2.最大并發(fā)用戶數(shù)：

顏色 比例 度量 最小值 平均值 最大值 SD

100 Apache CPU 使用情況(Apache):172.17.7.210 0.777 0.852 0.93 0.043

0.01 已發(fā)送 KB/秒(Apache):172.17.7.210 6 1430.371 2689.333 327.924

0.1 點(diǎn)擊次數(shù)/秒(Apache):172.17.7.210 0.333 114.352 533.667 40.201

應(yīng)用系統(tǒng)在當(dāng)前環(huán)境下能承受的最大并發(fā)用戶數(shù)。

在方案運(yùn)行中，如果出現(xiàn)了大批用戶的業(yè)務(wù)操作失敗，或出現(xiàn)了服務(wù)器shutdown的情況，則說(shuō)明在當(dāng)前環(huán)境下，系統(tǒng)承受不了當(dāng)前并發(fā)用戶的負(fù)載壓力，那么最大并發(fā)用戶數(shù)就是前一個(gè)沒(méi)有出現(xiàn)這種現(xiàn)象的并發(fā)用戶數(shù)。

從上圖可以看出：在測(cè)試運(yùn)行到4個(gè)小時(shí)左右的時(shí)候，apache的點(diǎn)擊數(shù)/秒開(kāi)始迅速增加!

3.業(yè)務(wù)操作響應(yīng)時(shí)間：

使用“事務(wù)性能摘要”圖，可以確定在方案執(zhí)行期間響應(yīng)時(shí)間過(guò)長(zhǎng)的事務(wù)。

顏色 比例 度量

1 最小值

1 平均值

1 最大值

分析事務(wù)的響應(yīng)情況，要每次詳細(xì)分析，目前還只能觀察到響應(yīng)時(shí)間過(guò)長(zhǎng)的事務(wù)!

4.每秒點(diǎn)擊數(shù)

負(fù)載測(cè)試期間每秒內(nèi) Vuser 在 Web 服務(wù)器上點(diǎn)擊的次數(shù)?？筛鶕?jù)點(diǎn)擊次數(shù)來(lái)估算 Vuser 生成的負(fù)載數(shù)。

顏色 比例 度量 圖最小值 平均值 圖最大值 圖中間值 圖SD

1 點(diǎn)擊次數(shù) 69.908 105.736 130.244 103.666 12.186

從圖中不難看出，在4小時(shí)的時(shí)候，點(diǎn)技數(shù)明顯增高。和apache的每秒點(diǎn)擊數(shù)增大的時(shí)間相吻合!

5.吞吐量

負(fù)載測(cè)試期間 Web 服務(wù)器上的吞吐量(字節(jié))。吞吐量表示在任何指定秒內(nèi) Vuser 從服務(wù)器接收到的數(shù)據(jù)量。此圖可估計(jì) Vuser 生成的負(fù)載量(服務(wù)器吞吐量)。

顏色 比例 度量 圖最小值 平均值 圖最大值 圖中間值 圖SD

1 Throughput 1257502.795 1375591.372 1525865.047 1372743.691 49130.473

同樣，從圖中可以看出，在4個(gè)小時(shí)的時(shí)候，web服務(wù)器的吞吐量開(kāi)始增高。在圖中還可以看到吞吐量的走勢(shì)圖，從開(kāi)始到進(jìn)行到4個(gè)小時(shí)反彈之前呈降低的趨勢(shì)，這是因?yàn)橄到y(tǒng)在初期調(diào)用的資源都是直接來(lái)之服務(wù)器，運(yùn)行一段時(shí)間后系統(tǒng)的部分資源來(lái)自緩存。

6.下載組件大小

每個(gè)頁(yè)面的組件大小，且包括組件的標(biāo)頭的大小!

頁(yè)面組件大小的分析表格比較復(fù)雜，實(shí)際分析中可以通過(guò)loadrunner的報(bào)告分析工具來(lái)分析。頁(yè)面組件大小分析主要是找到頁(yè)面中比較龐大的組件，如果其影響到了頁(yè)面的下載速度，則要想辦法將其改小!

7.Apache資源

顯示APACHE web服務(wù)器上的資源摘要。前面已經(jīng)提到過(guò)以并發(fā)點(diǎn)擊數(shù)為主。

顏色 比例 度量 最小值 平均值 最大值 SD

100 Apache CPU 使用情況(Apache):172.17.7.210 0.777 0.852 0.93 0.043

0.01 已發(fā)送 KB/秒(Apache):172.17.7.210 6 1430.371 2689.333 327.924

0.1 點(diǎn)擊次數(shù)/秒(Apache):172.17.7.210 0.333 114.352 533.667 40.201

三.服務(wù)器資源監(jiān)控指標(biāo)

　　(目前通過(guò)top監(jiān)察)

　　內(nèi)存：

　　Linux資源監(jiān)控中指標(biāo)內(nèi)存頁(yè)交換速率(Paging rate)，如果該值偶爾走高，表明當(dāng)時(shí)有線程競(jìng)爭(zhēng)內(nèi)存。如果持續(xù)很高，則內(nèi)存可能是瓶頸。也可能是內(nèi)存訪問(wèn)命中率低。

　　實(shí)際測(cè)試中，當(dāng)并發(fā)點(diǎn)擊數(shù)出現(xiàn)突然劇增前后，內(nèi)存的PR 值則居高25不下。說(shuō)明目前測(cè)試的系統(tǒng)中內(nèi)存存在瓶頸!

　　內(nèi)存資源成為系統(tǒng)性能的瓶頸的征兆:

　　很高的換頁(yè)率(high pageout rate);

　　進(jìn)程進(jìn)入不活動(dòng)狀態(tài);

　　交換區(qū)所有磁盤(pán)的活動(dòng)次數(shù)可高;

　　可高的全局系統(tǒng)CPU利用率;

　　內(nèi)存不夠出錯(cuò)(out of memory errors)

　　處理器：

　　Linux資源監(jiān)控中指標(biāo)CPU占用率持續(xù)超過(guò)80%(對(duì)該值的要求，根據(jù)具體應(yīng)用和機(jī)器配置而要求不同，有資料表明95%)，表明瓶頸是CPU。

　　實(shí)際測(cè)試中，當(dāng)并發(fā)點(diǎn)技數(shù)出現(xiàn)突然增加前后，cpu的占用率持續(xù)保持在86%以上!

　　說(shuō)明，目前系統(tǒng)用應(yīng)用的cpu也是測(cè)試的瓶頸!

　　CPU資源成為系統(tǒng)性能的瓶頸的征兆:

　　很慢的響應(yīng)時(shí)間(slow response time)

　　CPU空閑時(shí)間為零(zero percent idle CPU)

　　過(guò)高的用戶占用CPU時(shí)間(high percent user CPU)

　　過(guò)高的系統(tǒng)占用CPU時(shí)間(high percent system CPU)

　　長(zhǎng)時(shí)間的有很長(zhǎng)的運(yùn)行進(jìn)程隊(duì)列(large run queue size sustained over time)

　　四.數(shù)據(jù)庫(kù)服務(wù)器

　　數(shù)據(jù)庫(kù)服務(wù)器目前測(cè)試觀察，當(dāng)web服務(wù)器點(diǎn)擊率增大時(shí)，觀察mysql數(shù)據(jù)庫(kù)的最大連接數(shù)，仍未超過(guò)系統(tǒng)設(shè)置的最大連接數(shù)。所以，暫時(shí)未發(fā)現(xiàn)數(shù)據(jù)庫(kù)的瓶頸!

　　五.結(jié)論

　　以上報(bào)告分析中的數(shù)據(jù)、圖標(biāo)均來(lái)自同一次測(cè)試。是在平時(shí)測(cè)試中挑出的一次現(xiàn)象比較明顯，比較利于觀察的作為分析案例。

　　根據(jù)以上綜合分析，當(dāng)前測(cè)試環(huán)境下，當(dāng)應(yīng)用系統(tǒng)產(chǎn)生最大533.667的并發(fā)壓力。平均負(fù)載壓力114.352。根據(jù)分析，用戶在4個(gè)小時(shí)的時(shí) 候，并發(fā)數(shù)迅速增加前后的值在400左右!分析結(jié)果跟實(shí)際測(cè)試的硬件環(huán)境以及測(cè)試腳本有一定關(guān)系。同時(shí)，測(cè)試服務(wù)器的硬件配置和實(shí)際服務(wù)器的配置還有一定 的差距!