|
之前寫過一篇《在做性能測試之前應(yīng)該知道什么》有博文，自我感覺講的不好，舉了兩個(gè)例子，和做性能測試之前需要知道的一些要點(diǎn)。離我的題目有差距。二則覺得講的不全。其實(shí)，要做性能測試需要知道的東西太多了。豈是一篇博文都能說全的。在這里表示一下愧疚之情。 好多測試新手，在做完性能測試之后，不知如何對測試數(shù)據(jù)進(jìn)行分析。在這里我想談?wù)勔恍┬阅軠y試參數(shù)的相關(guān)知識(shí)。當(dāng)然，也不是一篇博文就能說清道明的。只希望在你的測試道路上能給你一絲幫助。 不怕啰嗦的再次忠告，那想成為測試高手的新人，多學(xué)學(xué)基礎(chǔ)知識(shí)。別把過多的時(shí)間放在研究新工具的使用上。工具何其多，原理差不多。不要本末倒置了。也算是自我提醒吧！
性能測試常見指標(biāo)
性能測試說白了就是通過工具模擬多個(gè)用戶對被測系統(tǒng)進(jìn)行訪問。然后查看系統(tǒng)對于多個(gè)用戶發(fā)來請求的處理能力。 左邊的兩個(gè)小人表示兩個(gè)用戶，向右邊服務(wù)器發(fā)送請求，然后得到服務(wù)器的響應(yīng)信息。 首先，我們要保證向服務(wù)器發(fā)送的請求的正確性，當(dāng)然用戶向服務(wù)器發(fā)送錯(cuò)誤的請求，服務(wù)器也會(huì)個(gè)客戶端響應(yīng)信息，但響應(yīng)的是報(bào)錯(cuò)信息；所以，為了保證測試數(shù)據(jù)的有效性，我們的要保證發(fā)送請求的正確性。 為什么一般的性能測試要在局域進(jìn)行？ 一般我們的性能測試都是在局域網(wǎng)中進(jìn)行的。為什么一定要在局域網(wǎng)中進(jìn)行呢？因?yàn)榫钟蚓W(wǎng)中不受網(wǎng)絡(luò)限制。這個(gè)說法不能絕對。但是一般測試工具的用戶并發(fā)量是不會(huì)受到局域網(wǎng)帶寬的限制，除非你做的是十萬，百萬級別的用戶并發(fā)。相信懂一點(diǎn)網(wǎng)絡(luò)知識(shí)的人都知道，當(dāng)你上網(wǎng)很慢的時(shí)候，比如打開某某網(wǎng)站很慢，你肯定會(huì)罵電信的網(wǎng)絡(luò)不給力，而不會(huì)罵這個(gè)網(wǎng)站響應(yīng)速度不給力。因?yàn)?，請求信息的耗時(shí)大部耗在傳輸過程中。 所以，剛做測試時(shí)，我們?nèi)豪餆嶙h論，如果我們每個(gè)人都開一個(gè)壓力工具對百度網(wǎng)站進(jìn)行加壓。百度，服務(wù)器會(huì)不會(huì)掛掉。有測友說這樣是不道德人。呵呵！其實(shí)，完全不必有這個(gè)擔(dān)心。就一般人家用的帶寬，我確保，你向百度服務(wù)器發(fā)送的請求大部分都死在半路上，就算不死到了百度服務(wù)器已經(jīng)不能叫并發(fā)了。何況百度服務(wù)器的集群技術(shù)以及其他各種分壓技術(shù)。所以，做性能測試不了解被測系統(tǒng)的架構(gòu)，以及各種技術(shù)的性能。很難做出有效的測試報(bào)告。 下面我們看看性能測試的一些技術(shù)指標(biāo)。 Work Load = Virtual Users 工作負(fù)荷 = 虛擬用戶數(shù) 對服務(wù)器產(chǎn)生多大壓力，可以由多少用戶同時(shí)對服務(wù)器發(fā)送請求來衡量。也就是服務(wù)器的性能可以看它同時(shí)處理多少用戶發(fā)送來的請求來衡量。
虛擬用戶數(shù)可以用進(jìn)程或線程的方式進(jìn)行模擬。
response time 響應(yīng)時(shí)間
從客戶端將數(shù)據(jù)包發(fā)出，到接收到服務(wù)器端發(fā)來的請求。這個(gè)過程的總體時(shí)間叫response time
這個(gè)時(shí)間用來衡量的處理請求的速度（拋出網(wǎng)速限制的前提下）
throughput ~Ti & To
這個(gè)表示，吞吐量，吞吐量越大表示系統(tǒng)性能越強(qiáng)。1個(gè)用戶跑100天和10個(gè)用戶跑1分鐘。當(dāng)然是1個(gè)用戶跑100天的吞吐量大。所以，我們要想看系統(tǒng)的性能應(yīng)該用“吞吐率”，就是單位時(shí)間的吞吐量，比如吞吐量/秒。
站在服務(wù)器端，T-in表示“吞”；T-out表求“吐”
Ti：T-in 主要衡量客戶端的能力，看客戶端往服務(wù)器發(fā)送的請求數(shù)據(jù)包的吞吐率。
To： T-out 主要衡量的服務(wù)器端的能力，看服務(wù)器處理返回請求數(shù)據(jù)包的吞吐率。
Hits/Request
網(wǎng)頁點(diǎn)擊數(shù)/請求
Response/Successful Response
響應(yīng)/成功的響應(yīng)
Request與Response是對應(yīng)，一個(gè)請求對應(yīng)一個(gè)響應(yīng)。但當(dāng)客戶端對服務(wù)器的壓力達(dá)到一直程度后，不是每一請求都能得到響應(yīng)的。去年末火了個(gè)最牛B的“電子商務(wù)”網(wǎng)站。12306（鐵路網(wǎng)上訂票系統(tǒng)），雖然有很差的用戶體驗(yàn)，但每天還是大把的人拼命的登錄（過年回家的人傷不起），甚至用外掛登錄。見有網(wǎng)友云云點(diǎn)擊（請求）了幾十幾百次才訂票（響應(yīng)）成功。所以，成功響應(yīng)率也是很重要的一個(gè)指標(biāo)?？蛻舳税l(fā)送一千個(gè)請求的成功得到響應(yīng)的幾率。
Hits Per Second
每秒中點(diǎn)擊次數(shù)
和吞吐量一樣，單單用點(diǎn)擊數(shù)（hits）來衡量系統(tǒng)也是不合理的。所以，用每秒鐘的點(diǎn)擊數(shù)才能衡量出服務(wù)器的處理能力。
響應(yīng)時(shí)間圖分析
橫坐標(biāo)表示用戶數(shù)
縱坐標(biāo)表示時(shí)間
紅色虛線，表求的是一種系統(tǒng)的理想狀態(tài)。
當(dāng)服務(wù)器處理10個(gè)用戶請求時(shí)所用的時(shí)間是2秒（假設(shè)），當(dāng)服務(wù)器處理200用戶請求時(shí)所用的時(shí)間也是2秒。所以說這種狀態(tài)是一種理想的狀態(tài)?，F(xiàn)實(shí)中，不管是如何超級強(qiáng)的服務(wù)器當(dāng)用戶數(shù)達(dá)到一定數(shù)量時(shí)，響應(yīng)時(shí)間必會(huì)變慢。
藍(lán)色斜線，是服務(wù)器常見的一種曲線狀態(tài)。
服務(wù)器的響應(yīng)時(shí)間雖然用戶數(shù)量的增加逐漸變慢。
當(dāng)系統(tǒng)出現(xiàn)這種斜線，應(yīng)該說系統(tǒng)性能是相當(dāng)健壯的。隨著用戶的增長響應(yīng)時(shí)間逐漸變長。
黑色曲線，個(gè)人覺得是服務(wù)器處理能力的真實(shí)曲線狀態(tài)。
為什么說黑線才是真實(shí)服務(wù)器處理能力的曲線呢？當(dāng)用戶處理一個(gè)用戶請求是2秒（假設(shè)），當(dāng)處兩個(gè)用戶請求是馬上變成3秒（假設(shè)），當(dāng)處理3個(gè)用戶請求時(shí)變成4秒（假設(shè)）。再差的服務(wù)器也有個(gè)處理范圍，比如是，100用戶同時(shí)并發(fā)，服務(wù)器可以輕松應(yīng)對，不管是10個(gè)用戶還是80個(gè)用戶同時(shí)請求，服務(wù)器都可以即可響應(yīng)（請參考理發(fā)店模式）。只有當(dāng)用戶數(shù)量達(dá)到某個(gè)數(shù)量點(diǎn)后，服務(wù)器性能急劇下降。如上圖黑色十字星處就是系統(tǒng)的拐角點(diǎn)。
我們假設(shè)有一個(gè)門，在一個(gè)時(shí)間點(diǎn)上可同時(shí)過10個(gè)人，不管你是同時(shí)來3個(gè)還是10個(gè)都可以在同一時(shí)間點(diǎn)過門，假如來了11個(gè)人，必然有一個(gè)人要等10個(gè)人過門之后才能過。那么當(dāng)超過10人來過門時(shí)，過門的速度就開始變慢。那么10就是服務(wù)器性能的拐角點(diǎn)。我們通常做壓力測試找服務(wù)器的拐角點(diǎn)是很重要的任務(wù)之一。
關(guān)藍(lán)色曲線與黑色區(qū)線只是我們常見兩種曲線?，F(xiàn)實(shí)的測試中可能出現(xiàn)各種樣式的曲線。當(dāng)然還要看你做測試的細(xì)度，比如，10個(gè)用戶是系統(tǒng)的拐點(diǎn)，如果你做完5個(gè)用戶的一輪測試后，就是20用戶的測試。那么畫出來的曲線就變成斜線，拐點(diǎn)將被護(hù)忽略掉。
吞吐率圖分析
橫坐標(biāo)虛擬用戶數(shù)
縱坐標(biāo)有吞吐率（服務(wù)器端）
紅色虛線，表示一種理想的狀態(tài)。
隨著用戶數(shù)量的增加吞吐率也在持續(xù)增加。
黑色曲線，表示現(xiàn)實(shí)系統(tǒng)的吞吐率狀態(tài)。
剛開始吞吐率隨著用戶數(shù)量的增加逐漸變大，當(dāng)大到一定程度時(shí)，逐漸平緩直到變成一條平線。
如果用戶還在持續(xù)增加中，那么吞吐率有可能下降，直到系統(tǒng)掛掉。
為什么會(huì)是這樣呢？我們通過另一個(gè)例子來說，大家都在城市生活，相信上下班高峰期都會(huì)遇到堵車。在比較重要的紅綠燈路口常會(huì)見到堵車現(xiàn)象。假如每個(gè)綠燈可以通過10輛，前期來三五輛車，遇到綠燈，一次都過去了。到了下班高峰期，車子變多，一下來了20輛，但這個(gè)路口的綠燈每天只能通過10輛，所以，這個(gè)時(shí)候，路口的通過率不會(huì)根據(jù)車輛的增加而繼續(xù)增加。
好的系統(tǒng)好像好有個(gè)好的交警在位置秩序，雖然車輛還在增加，但每個(gè)車輛都有條不紊等待通過路口。
不好的系統(tǒng)如路口趕上交警拉肚子，車輛在增加，后面車輛等得不耐煩就往前擠，結(jié)果稿得互不相讓。好嘛！之后還每個(gè)綠燈可通過10輛，現(xiàn)在只能有一輛車從夾縫中脫離苦海了。
響應(yīng)時(shí)間圖與吞吐率圖并不是我們一輪性能測試下來就能得到結(jié)果。需要經(jīng)過多輪測試才能得到。設(shè)置不同的用戶數(shù)量，得到每次的測試數(shù)據(jù)，將每次數(shù)據(jù)連接，從而得到最終系統(tǒng)性能曲線。關(guān)于用戶數(shù)量每次增加的數(shù)量自己把握。如果，想精確，可以每次增加1個(gè)用戶的方式來做，不過這樣勢必加大工作量，也沒必要。這個(gè)需要每做完一輪測試后對數(shù)據(jù)進(jìn)行分析，然后確定下輪測試所要設(shè)置的虛擬用戶數(shù)。
關(guān)于，性能指標(biāo)的分析，就先談到這里。關(guān)于內(nèi)容，我反復(fù)經(jīng)過思考，但難免有理解有誤之處。還望高手點(diǎn)撥。共同進(jìn)步。
|
|
|
