1 怎樣的性能測(cè)試結(jié)果才是有效的

1.1 錯(cuò)誤觀點(diǎn)

性能測(cè)試工具運(yùn)行一定用戶數(shù)都成功，則表示該服務(wù)器能支持這么多用戶數(shù)。這是錯(cuò)誤的。

解答：

A. 因?yàn)橐淮斡行У臏y(cè)試結(jié)果，不只用戶都運(yùn)行成功，同時(shí)需要保證訪問(wèn)一個(gè)頁(yè)面或一次交易的響應(yīng)時(shí)間在合理范圍。“2-5-8原則”，簡(jiǎn)單說(shuō)，就是當(dāng)用戶訪問(wèn)一個(gè)頁(yè)面或一次交易能夠在2秒以內(nèi)得到響應(yīng)時(shí)，會(huì)感覺(jué)系統(tǒng)的響應(yīng)很快；當(dāng)用戶在2-5秒之間得到響應(yīng)時(shí)，會(huì)感覺(jué)系統(tǒng)的響應(yīng)速度還可以；當(dāng)用戶在5-8秒以內(nèi)得到響應(yīng)時(shí)，會(huì)感覺(jué)系統(tǒng)的響應(yīng)速度很慢，但是還可以接受；而當(dāng)用戶在超過(guò)8秒后仍然無(wú)法得到響應(yīng)時(shí)，會(huì)感覺(jué)系統(tǒng)糟透了，或者認(rèn)為 系統(tǒng)已經(jīng)失去響應(yīng)，而選擇離開(kāi)這個(gè)Web站點(diǎn)，或者發(fā)起第二次請(qǐng)求。

B. 測(cè)試場(chǎng)景不一定模擬了真實(shí)業(yè)務(wù)場(chǎng)景，因?yàn)闉g覽器是并發(fā)多線程多TCP完成一個(gè)頁(yè)面的，而測(cè)試工具基本都是1，2個(gè)線程；對(duì)服務(wù)器的壓力是不一樣的，真實(shí)環(huán)境的TCP壓力是性能測(cè)試工具虛擬環(huán)境的幾倍。

2 影響WEB服務(wù)器性能指標(biāo)的因素有哪些

為什么性能測(cè)試工具，需要提供事務(wù)（頁(yè)面或交易、全腳本）指標(biāo)、TCP連接、吞吐量、服務(wù)器資源監(jiān)控、請(qǐng)求數(shù)/響應(yīng)數(shù)。

1.  硬件資源：如CPU、內(nèi)存、網(wǎng)卡吞吐量、I/O能力、SWAP交換能力
2.  線程數(shù)：這里介紹JAVA的WEB服務(wù)器，默認(rèn)每線程占用的內(nèi)存為2M，而32為系統(tǒng)JAVA進(jìn)程（如tomcat、JBoss）占得空間只有2G（一般比這個(gè)小），因此線程數(shù)有限制；64為無(wú)限制線程，但CPU要跟得上
3.  TCP連接數(shù)：操作系統(tǒng)的TCP連接數(shù)理論值一般很大，操作系統(tǒng)對(duì)TCP連接設(shè)置有默認(rèn)值（怎么配置，可以網(wǎng)上搜索，這里不介紹）；但實(shí)際測(cè)試中TCP連接在幾百，就出現(xiàn)測(cè)試的響應(yīng)時(shí)間很長(zhǎng)。抓包分析，原來(lái)是三次握手的SYN包服務(wù)器不及時(shí)響應(yīng)，導(dǎo)致SYN重傳（3秒后，9秒后）。
4. 如果SYN丟了，則會(huì)重發(fā)，但是第一次是3秒后，第2次是在9秒后，如果重發(fā)才收到的SYN_ACK，則導(dǎo)致TCP連接超長(zhǎng)，從而導(dǎo)致業(yè)務(wù)響應(yīng)時(shí)間延長(zhǎng)。
5.  響應(yīng)時(shí)間：服務(wù)器響應(yīng)時(shí)間小，用戶體驗(yàn)才好，在大量用戶并發(fā)的情況下，HTTP響應(yīng)時(shí)間在用戶忍受度下才是有效的，一般采用“2-5-8原則”。
6.  軟件本身代碼性能算法：這個(gè)不做介紹，如差的算法、查詢數(shù)據(jù)庫(kù)時(shí)間長(zhǎng)等等。

3 測(cè)試人員經(jīng)常遇到的一些常見(jiàn)問(wèn)題及解答

3.1為什么使用瀏覽器訪問(wèn)頁(yè)面響應(yīng)很快，1-2秒就完成；而使用測(cè)試工具卻需要10幾秒，甚至幾十秒才完成腳本

解答：

A. 這是由于瀏覽器訪問(wèn)頁(yè)面響應(yīng)是并發(fā)的，同時(shí)并發(fā)多個(gè)線程（多個(gè)Socket），而性能測(cè)試工具基本是串行發(fā)送請(qǐng)求的。如果一個(gè)頁(yè)面有100個(gè)資源（CSS、HTML、JS、圖片），需要發(fā)送100個(gè)HTTP請(qǐng)求，如果使用6個(gè)線程（瀏覽器），則每個(gè)大概請(qǐng)求14個(gè)HTTP；如果使用一個(gè)線程（測(cè)試工具），則需要請(qǐng)求100個(gè)，時(shí)間當(dāng)然大很多。下圖為chrome瀏覽器調(diào)試工具顯示的并發(fā)情況

B. 另外瀏覽器具有緩存功能，如果之前訪問(wèn)了www.qq.com，會(huì)把一些圖片緩存在瀏覽器臨時(shí)目錄，下次請(qǐng)求時(shí)發(fā)送的HTTP請(qǐng)求會(huì)帶上If-Match或Etag等頭域，WEB服務(wù)器判斷資源沒(méi)改變則會(huì)304響應(yīng)，而不是回200 OK，這樣減少資源的傳輸，所以時(shí)間就小。而有些測(cè)試工具是不攜帶這些頭域（包括Loadrunner），因此回的響應(yīng)是200 OK。所以測(cè)試人員默認(rèn)真實(shí)測(cè)試時(shí)，可以考慮部分有緩存，部分沒(méi)緩存。

3.2性能測(cè)試工具是怎么模擬WEB虛擬用戶

A. 錄制

使用瀏覽器進(jìn)行正常業(yè)務(wù)操作，性能測(cè)試工具錄制下HTTP請(qǐng)求信息。一般需要記錄URL與頭域、內(nèi)容、響應(yīng)碼。雖然不同的性能測(cè)試工具錄制方式不一樣（如loadrunner采用Hook，JMeter采用代理或badbody，kylinPET采用網(wǎng)卡抓包與代理），但都能實(shí)現(xiàn)錄制正常業(yè)務(wù)的 HTTP請(qǐng)求。

測(cè)試工具最好能錄制出緩存頭域，即If-Match或Etag，loadrunner好像不支持錄制緩存頭域。

B.模擬用戶

根據(jù)錄制的腳本發(fā)送HTTP請(qǐng)求與接收響應(yīng)，發(fā)送前替換參數(shù)（實(shí)現(xiàn)多用戶不同參數(shù)值）、接收時(shí)關(guān)聯(lián)參數(shù)（從接收的響應(yīng)消息獲取參數(shù)值，如Cookie、JSessionID）

下面簡(jiǎn)單列舉使用過(guò)的性能測(cè)試工具是如何模擬的（工具運(yùn)行一個(gè)用戶，然后使用wireshark抓包分析得到的結(jié)論）：

• Loadrunner：根據(jù)錄制腳本發(fā)送HTTP請(qǐng)求，如果HTTP請(qǐng)求包括內(nèi)嵌資源（如圖片、CSS、JS），會(huì)啟動(dòng)第二個(gè)線程執(zhí)行內(nèi)嵌資源，即Loadrunner支持同時(shí)兩個(gè)線程兩個(gè)TCP連接。
• kylinPET（國(guó)產(chǎn)）：可通過(guò)配置設(shè)置一個(gè)線程或者多個(gè)線程并發(fā)發(fā)送HTTP請(qǐng)求，多個(gè)線程并發(fā)及TCP連接數(shù)跟瀏覽器行為一樣。
• JMeter：只有一個(gè)線程，一個(gè)TCP連接
• 其他工具：本人沒(méi)用過(guò)，請(qǐng)用過(guò)的兄弟姐妹可以補(bǔ)充下。通過(guò)wireshark抓包分析。

3.3怎樣才能測(cè)試出WEB服務(wù)器能支持多少真實(shí)用戶，怎樣的服務(wù)器調(diào)優(yōu)參數(shù)才合理

解答：

這需要性能測(cè)試工具可以模擬出真實(shí)用戶的行為，包括HTTP請(qǐng)求數(shù)、每用戶并發(fā)線程與TCP連接數(shù)、思考時(shí)間、有無(wú)緩存。

為什么需要模擬真實(shí)用戶的線程數(shù)與TCP連接數(shù)呢，上面提到過(guò)，WEB服務(wù)器的線程數(shù)與TCP連接數(shù)往往很低，這不是提高硬件就能輕松解決的，這也是服務(wù)器調(diào)優(yōu)比較復(fù)雜的配置。

因此，只有盡最大能力模擬真實(shí)用戶（瀏覽器或其它WEB客戶端，可能不同瀏覽器的并發(fā)線程與TCP數(shù)都不一樣）的行為的測(cè)試場(chǎng)景，測(cè)試結(jié)果才最真實(shí)，服務(wù)器調(diào)優(yōu)才最有意義。

4 怎樣才能測(cè)試系統(tǒng)支持多少用戶

4.1 模擬真實(shí)用戶的行為

只有模擬用戶一樣的行為才可以系統(tǒng)支持的測(cè)試用戶數(shù)有效，因此需要模擬一樣的并發(fā)數(shù)、TCP連接數(shù)、甚至可以是HTTP請(qǐng)求的時(shí)間間隔。用戶可以是瀏覽器、智能手機(jī)、智能機(jī)頂盒，測(cè)試工具模擬他們一樣的行為才是最有效的測(cè)試。

4.2 測(cè)試結(jié)果數(shù)據(jù)在合理范圍

4.2.1 用戶統(tǒng)計(jì)

成功數(shù)、失敗數(shù)、每秒在線數(shù)、最大在線數(shù)，通過(guò)這些指標(biāo)分析此次測(cè)試結(jié)果支持的用戶數(shù)、用戶最大數(shù)

4.2.2 點(diǎn)擊率

每秒平均HTTP請(qǐng)求數(shù)、響應(yīng)數(shù)。分析系統(tǒng)的處理能力

4.2.3 事務(wù)

事務(wù)成功、失敗、時(shí)間，事務(wù)一般是整個(gè)腳本運(yùn)行時(shí)間、或者一個(gè)頁(yè)面或一個(gè)交易，通過(guò)結(jié)果分析，得出每個(gè)事物的時(shí)間是否合理，符合“2-5-8”原則，如果測(cè)試結(jié)果顯示事物時(shí)間非常大，則表示系統(tǒng)支持不了此次測(cè)試的用戶，因?yàn)橛脩舻捻憫?yīng)時(shí)間太大（像火車訂票一樣，太多用戶導(dǎo)致響應(yīng)時(shí)間長(zhǎng)，用戶無(wú)法忍受，則認(rèn)為這個(gè)系統(tǒng)爛）。

當(dāng)然，還需要查看事務(wù)的百分比，分析90%、80%、70%、60%的事務(wù)時(shí)間是否在合理范圍。

4.2.4 TCP連接信息

TCP連接成功數(shù)、失敗數(shù)、TCP三次握手時(shí)間。因?yàn)榇舜螠y(cè)試結(jié)果可能是由于服務(wù)器系統(tǒng)或網(wǎng)絡(luò)的TCP的丟包與重傳才導(dǎo)致延時(shí)大的。如果是服務(wù)器的原因，服務(wù)器收到TCP的SYN而不處理，可以通過(guò)調(diào)試服務(wù)器的TCP配置來(lái)優(yōu)化。

怎么才知道是服務(wù)器的問(wèn)題呢，這個(gè)需要性能測(cè)試工具能給出TCP連接時(shí)間（當(dāng)前了解只有kylinPET可以支持），如果顯示超過(guò)3秒，這時(shí)需要檢查是網(wǎng)絡(luò)還是服務(wù)器問(wèn)題，可以在服務(wù)器端抓包（tcpdump或wireshark）然后分析TCP的SYN信息（個(gè)數(shù)、時(shí)間）

4.2.5 資源占用

服務(wù)器的CPU、內(nèi)存、帶寬、I/O是不是已經(jīng)不足，導(dǎo)致系統(tǒng)上不去是哪個(gè)原因，根據(jù)原因進(jìn)行調(diào)優(yōu)或升級(jí)。

測(cè)試時(shí)需要考慮性能測(cè)試工具的CPU占用率，如果性能測(cè)試工具占用CPU很高，此次測(cè)試可能瓶頸是在工具，而導(dǎo)致測(cè)試結(jié)果是無(wú)效的。

原文鏈接：http://bbs.51testing.com/thread-980437-1-1.html