1. 程式人生 > >loadrunner的響應時間

loadrunner的響應時間

1. 響應時間 

事務是指使用者在客戶端做一種或多種業務所需要的操作集,通過事務函式可以標記完成該業務所需要的操作內容;另一方面事務可以用來統計使用者操作的響應時間,事務響應時間是通過記錄使用者請求的開始時間和伺服器返回內容到客戶端時間的差值來計算使用者操作響應時間的,如圖1所示。

這裡的響應時間不包含客戶端GUI時間(例如瀏覽器解釋頁面所消耗的時間)。 前面說響應時間是使用者請求發出和伺服器返回之間的時間差,那麼得到這個時間就夠了嗎? 
例如:現在有一場跑步比賽。當比賽完成後,可以得到每位運動員跑完整個比賽所需要消耗的時間,現在需要分析誰的起跑好、誰的衝刺好,能分析出來嗎?答案是不能,雖然得到了最重要的完成比賽的響應時間,但是這對分析和優化幾乎沒有作用,因為只知道了結果而不知道過程。跑步的時間是由起跑、中途、衝刺等時間組成的,如果想要進行分析優化,必須先了解各個階段所花費的時間和速度以及各個運動員的優缺點。 
對於軟體來說,通過事務得到的系統響應時間也是由非常多的部分組成的,一般來說響應時間由網路時間、伺服器處理時間、網路延遲三大部分組成。先來看看當一個客戶端發出請求到伺服器返回需要經歷哪些路徑,如圖2所示。 

1.網路時間 
客戶端發出請求首先通過網路來到Web Server上(消耗時間為N1);然後Web Server將處理後的請求傳送給App Server(消耗時間為N2);App Server將操作資料指令傳送給Database (消耗時間為N3);Database伺服器將查詢結果資料傳送回App Server(消耗時間為N4);App Server將處理後的頁面發給Web Server(消耗時間為N5);最後Web Server將HTML轉發到客戶端(消耗時間為N6)。這裡的Nx都是網路傳輸上的時間開銷,沒有計算業務處理所需要花費的時間。 
2.伺服器處理時間 
另外一個方面還要考慮各個伺服器處理所需要的時間WT、AT、DT。 3.網路延遲 
除了上面兩種時間開銷以外,還要考慮網路延遲的問題。 所以最終的響應時間組成為: 
響應時間 = 網路延遲時間 + WT+AT+DT +(N1+N2+N3)+(N4+N5+N6)+ WT+AT+DT 也可以簡單認為響應時間由網路開銷(前端)和伺服器開銷(後端)兩大部分組成,如圖3所示。 

那麼這些消耗的時間都花在什麼事情上了呢?影響網路的因素一般包括以下內容: 1.

前端Network DNS Lookup 

Time to connect 

Time to first buffer 

Network Time

 Download Time 

SSL handshake 

FTP authentication 

Client Time 

Error Time  網路延遲 

2.後端服務

 Web Server 

Servlet Time

Method Time 

靜態動態壓縮 

App Server

 EJB Time 

Method Time 

JNDI Lookup 

Database Server 

JDBC Time 

Connect Time 

Execute Time

這裡會發現響應時間的組成是非常複雜的,當效能問題出現時,想要定位到具體的程式碼級別是相當困難的。 
LoadRunner只能對自己發出的請求和伺服器返回的內容進行網路級別的分析,也就是說LoadRunner能夠分析的時間為客戶到WWW伺服器的時間N1和WWW伺服器返回到客戶的時間N6。這些時間主要和網路速度有關,可以用一個LoadRunner的名稱來解釋,叫做Web Page Breakdown。 
也就是說VuGen可以分析的時間只有客戶端到Web Server之間的部分,後面從Web Server到App Server再到Database Server的時間只能得到一個總和。 
2.  事務時間 
一個事務的時間是指持續時間,事務會完全記錄下從事務開始到事務結束之間的時間差,那麼事務的時間能真實地反映業務操作的時間嗎?不能,就好像人用手按秒錶來記錄短跑時間一樣,得出的時間並不是完全準確,存在觀察的誤差和操作的誤差,對於一個事務時間來說,一般由四部分組成,如圖4所示




  





  


除了指令碼自身浪費的時間,某些時候使用C語言等外部介面進行處理所消耗的時間也會影響事務的時間,而這個時間LoadRunner無法處理,在這種情況下就需要人為地計算第三方時間開銷,並且將這個開銷的時間記入Wasted Time中。 
執行一下下面的程式碼: 
1. Action()    2. {    
3.     int i;   
4.     int baseIter = 100;    5.     char dude[1000];    
6.     merc_timer_handle_t timer;    
7.     // Examine the total elapsed time of the action    8.     //Start transaction    
9. 
    lr_start_transaction("Demo");    
10.     timer=lr_start_timer();   
11.     for (i=0;i<=baseIter*1000;i++) {   
12.           sprintf(dude,"This is the way we waste time in a script = 
              %d", i);   13.            }   
14.      wasteTime=lr_end_timer(timer); //時間單位為毫秒  
15.     lr_wasted_time(wasteTime*1000);//將wasteTime轉換為秒並計入lr的
Wasted Time,當在場景中執行的時候,事務的響應時間會自動扣除Wasted Time 16.     lr_end_transaction("Demo", LR_AUTO);    17.     return 0;    18. }  
其中,lr_start_timer()是一個LoadRunner自帶的時間計數器,它和lr_end_timer()相對應,能夠返回這兩個函式間的時間差。 
執行指令碼後,等待一段時間指令碼執行結束,可以看到以下日誌。 
1. Action.c(18): Notify: Transaction "Demo" started.   2. Action.c(27): wasted time is 85.860000   
3. 
Action.c(28): Notify: Transaction "Demo" ended with  "Pass" status (Duration: 85.8772 Wasted Time: 85.8600).  
通過上面這個日誌可以看到,在VuGen執行指令碼的時候這個1000次的C語言操作所消耗的時間會被算在Transaction時間內,導致Transaction的時間變長。當通過lr_start_timer()計時函式將這個消耗時間加入Wasted Time後,這個指令碼就能正確地計算出事務的時間和該



  


事務時間的Wasted Time了。當在場景中執行的時候,事務的響應時間會自動扣除Wasted Time。 
為了確保響應時間的正確,需要扣除在執行指令碼時自身的時間消耗,事務中儘量避免出現非請求的處理內容,如果無法避免請使用lr_wasted_time()函式將多餘的時間開銷扣除。 
例如這樣的指令碼: 
1. merc_timer_handle_t timer; //變數宣告   2. lr_start_transaction("Demo");    3. timer=lr_start_timer();   4. lr_load_dll("getkey.dll");   
5. lr_save_string(getrandkey(),"key");   6. //通過呼叫dll獲得金鑰   
7. wasteTime=lr_end_timer(timer);   8. lr_wasted_time(wasteTime*1000);    9. 
lr_end_transaction("Demo", LR_AUTO);   
計算金鑰是很消耗時間的,那麼可以使用timer這個變數來記錄計算的時間,並將這個時間從整個事務中扣除。 
在計算Wasted Time時不要直接使用lr_wasted_time()覆蓋,而忘了加上指令碼中LoadRunner函式的自身時間。通過lr_get_transaction_wasted_time()函式可以獲得事務自身的Wasted Time,將這個時間累加上第三方統計的Wasted Time再通過lr_wasted_time()函式覆蓋。 
3.手工事務 
前面都是使用LR_AUTO來自動判斷事務狀態,現在來做一個指令碼,看看LoadRunner的事務是如何自動判斷狀態的。 
錄製一個論壇註冊使用者的指令碼,在提交登錄檔單處新增事務開始及結束標誌,然後回放該指令碼。事務的結果是PASS還是FAIL呢?雖然回放指令碼註冊使用者是失敗的(該使用者已經存在),但是事務還是在PASS狀態下完成了,而且會發現事務的持續時間很短。正常情況下注冊一個使用者到重新整理首頁一般都要2秒,現在只需要0.3秒。這是因為當伺服器判斷到該使用者已存在後,就沒有了資料插入和等待1秒重新整理首頁的操作,而是直接返回錯誤提示頁面。這個0.3秒是系統處理錯誤的時間而不是註冊使用者所需要的時間。 
LR_AUTO也是根據伺服器的返回狀態資訊來決定事務是以LR_PASS狀態通過還是以LR_FAIL狀態結束,只要伺服器返回頁面,那麼事務就會認為請求成功發出去了,伺服器看懂了請求也返回了內容,自然事務是PASS狀態了。 



  


這樣由於事務自動判斷的錯誤,導致雖然操作是失敗的,但得到了一個響應時間,並且這個響應時間又沒有正確反映出做這件事情的真正時間,最終就會影響到效能測試得到的資料。 
記得在論壇上就有朋友問過這樣的問題,為什麼系統在使用者越來越多的情況下,響應時間不增反減?這種現象很有可能就是沒有使用手工事務導致的結果。 
對於這種情況就需要手工來判斷操作是否成功,通過web_reg_find()檢查點函式來檢查頁面是否返回正確,然後通過rowcount的引數值來進行事務狀態判斷,做到智慧判斷事務結果。 
例如:檢查點函式的rowcount儲存在引數loginst中,那麼事務的狀態就應該這樣判斷: 
1. lr_start_transaction("login");   2. web_reg_find("Search=Body",   3.         "SaveCount=loginst",   4.         "Text=登入失敗",   5.         LAST);   6. //登入請求   
7. If(atoi(lr_eval_string("{loginst}"))>=1))   8.         lr_end_transaction("login", LR_FAIL);   9. 
else   
10.         lr_end_transaction("login",LR_PASS);  
通過檢查點來檢查登入後頁面是不是存在"登入失敗"這樣的內容,如果存在那麼loginst的值就大於等於1,然後把loginst的值取出來和1做比較,如果大於1那麼就是登入失敗,否則就是登入成功。 
引數不能和值做比較,所以要先通過lr_eval_string()函式將其轉化成字串,然後再通過atoi()函式轉化成整數,這樣才能和1作比較。 
在絕大多數情況下對於事務都需要採用手工事務的方式來確保事務的正確性和事務時間的有效性。 
思考題: 
對於Discuz論壇來說如何做一個有效的使用者註冊指令碼通過手工事務並且獲得準確註冊操作的響應時間。 
業務分析: 
註冊使用者後,在系統的頁面上會出現【歡迎:註冊使用者名稱】的資訊,可以在註冊後返回的頁面中檢查是否出現了這樣的內容來判斷註冊事務是否成功。 

通過檢查頁面可以得到需要判斷的程式碼為: 
1. 
 
歡迎:<a class="dropmenu" id="viewpro" onmouseover="showMenu(this.id)">  
所以在檢查點函式中需要新增這個內容,為了更好地判斷,還需要把註冊使用者的名字也加進去,最後可以得到下面的程式碼: 
1. Action()   2. {   
3.         web_url("註冊",   
4.             "URL=http://192.168.0.200/register.aspx",   5.             "TargetFrame=",   6.             "Resource=0",   
7.             "RecContentType=text/html",   8.             "Referer=http://192.168.0.200/",   9. 
            "Snapshot=t2.inf",   
10.             "Mode=HTML",   11.             EXTRARES,   
12.             "URL=/templates/default/images/check_error.gif", ENDITEM
,   
13.             "URL=/templates/default/images/check_right.gif", ENDITEM
,   
14.             "URL=/images/level/3.gif", ENDITEM,   15.             LAST);   16.        
17.         lr_start_transaction("reg");   18.        
19.         web_reg_find("Search=Body",   20.             "SaveCount=regst",   
21.             "Text=歡迎:<a class=\"dropmenu\" id=\"viewpro\" 
onmouseover= \"showMenu(this.id)\">{username}",   22.             LAST);   23.        
24.         web_submit_data("register.aspx",   
25.             "Action=http://192.168.0.200/register.aspx?createuser=1"
,   
26.             "Method=POST",   27.             "TargetFrame=",   
28.             "RecContentType=text/html",   



  


29.             "Referer=http://192.168.0.200/register.aspx",   30.             "Snapshot=t11.inf",   31.             "Mode=HTML",   32.             ITEMDATA,  
33.             "Name=username", "Value={username}", ENDITEM,   34.             "Name=password", "Value=112212", ENDITEM,   35.             "Name=password2", "Value=112212", ENDITEM,  
36.             "Name=email", "Value={username}@cloud.chen", ENDITEM,   37.             "Name=submit", "Value=建立使用者", ENDITEM,   38.             "Name=question", "Value=0", ENDITEM,   39.             "Name=answer", "Value=", ENDITEM,   40.             "Name=realname", "Value=", ENDITEM,   41.             "Name=idcard", "Value=", ENDITEM,   42.             "Name=mobile", "Value=", ENDITEM,   43.             "Name=phone", "Value=", ENDITEM,   44.             "Name=gender", "Value=0", ENDITEM,   45.             "Name=nickname", "Value=", ENDITEM,   46.             "Name=bday_y", "Value=", ENDITEM,   47.             "Name=bday_m", "Value=", ENDITEM,   48.             "Name=bday_d", "Value=", ENDITEM,   49.             "Name=location", "Value=", ENDITEM,   50.             "Name=msn", "Value=", ENDITEM,   51.             "Name=yahoo", "Value=", ENDITEM,   52.             "Name=skype", "Value=", ENDITEM,   53.             "Name=icq", "Value=", ENDITEM,   54.             "Name=qq", "Value=", ENDITEM,   55.             "Name=homepage", "Value=", ENDITEM,   56.             "Name=bio", "Value=", ENDITEM,  
57.             "Name=templateid", "Value=0", ENDITEM,   58.             "Name=tpp", "Value=0", ENDITEM,   59.             "Name=ppp", "Value=0", ENDITEM,  
60.             "Name=newpm", "Value=radiobutton", ENDITEM,   61.             "Name=pmsound", "Value=1", ENDITEM,   62.             "Name=showemail", "Value=1", ENDITEM,   63.             "Name=receivesetting", "Value=2", ENDITEM,   64.             "Name=receivesetting", "Value=4", ENDITEM,   65.             "Name=invisible", "Value=0", ENDITEM,   66.             "Name=signature", "Value=", ENDITEM,  



  


67.             "Name=sigstatus", "Value=1", ENDITEM,   68.             LAST);   69.        
70.         if(atoi(lr_eval_string("{regst}"))>=1)   71.             lr_end_transaction("reg", LR_PASS);   72.         else   
73.             lr_end_transaction("reg",LR_FAIL);   74.         return 0;   75.     }  
這裡的{username}是一個引數,用來存放註冊的使用者名稱,在引數列表中設定了該引數的取值方式和資訊。  

相關推薦

轉:LoadRunner響應時間與使用者體驗時間不一致問題的深入分析

LoadRunner執行web_url()語句時,請求資源的先後順序不依賴程式碼書寫順序,導致很難直接確定執行web_url()的開始時間,但可以藉助LoadRunner的分析工具模組頁面診斷器(Web Page Diagnostics)獲取事務開始時刻和結束結束。在Web Page Diagnostics

loadrunner controller 裡響應時間不顯示

有時候,我們錄製好指令碼,儲存後,在loadrunner controller裡壓測,發現controller的響應時間不顯示,怎麼解決呢; 重新錄製?no no no 解決辦法是在腳本里面新增事務, 這樣更有效的統計了指令碼的響應時間。

JMeter 像 LoadRunner 那樣實時檢視每秒事務數(TPS)、事務響應時間(TRT)

出處:http://blog.csdn.net/defonds/article/details/54576604熟悉 LoadRunner 的朋友一定不會對其 TPS(每秒事務數)、TRT(事務響應時間) 等檢視感到陌生,因為這是壓力測試最為關鍵的兩個指標。JMeter 以其

Loadrunner做效能測試:為什麼100個使用者的響應時間反而比50個使用者的響應時間更短?

我在中國外匯交易中心工作過一段時間,當時有個專業的Loadrunner測試團隊,他們的測試結果:為什麼100個使用者的響應時間反而比50個使用者的響應時間更短。分析:首先這肯定是一種不正常的現象,因為

LoadRunner:Controller及結果分析 一、效能測試概述 1、關於效能測試目標: ①TPS ②一定併發使用者數下功能點的響應時間 ③一定響應時間內功能點的併發使用者數 效能測試不是

一、效能測試概述 1、關於效能測試目標: ①TPS ②一定併發使用者數下功能點的響應時間 ③一定響應時間內功能點的併發使用者數 效能測試不是達到既定目標即可,還要測試軟體功能能夠達到的極限值。 2、關於效能測試的場景: 在指令碼錄製除錯完成後,需要進行場景的設定,進而對指令碼進行壓測,分析壓測的結果。 效能

loadrunner結果分析中的響應時間理解

有些事情其實並不複雜,只不過我們沒有關注他,或者說我們沒有很好的關注,我們在用LR做效能測試的時候有一個很重要的指標,響應時間,大家都知道這個指標,也知道這個指標可以在結果分析中哪裡得到,但是又有多少人知道LR給出的這些值是如何得到的呢?今天在這篇我們中我就給大家揭祕這個

loadrunner響應時間

1. 響應時間  事務是指使用者在客戶端做一種或多種業務所需要的操作集,通過事務函式可以標記完成該業務所需要的操作內容;另一方面事務可以用來統計使用者操作的響應時間,事務響應時間是通過記錄使用者請求的開始時間和伺服器返回內容到客戶端時間的差值來計算使用者操作響應時間的,如圖

loadrunner:併發使用者90%的響應時間的用法

篇討論的是基於LoradRunner的效能測試,併發使用者90%的響應時間的用法。假設90%是14.721秒。 90Percent:是指把響應時間從小到大排序,90%的響應時間,在14.721秒這個範圍之內; 1)這個90%是可以調的,方法:選擇Tools/options/

loadrunner中的響應時間

LoadRunner 是以客戶端的角度來定義“響應時間”的,當客戶端請求發出去後, LoadRunner 就開始計算響應時間,一直到它收到伺服器端的響應。這個時候問題就產生了:如果此時的伺服器端的排隊佇列已滿,伺服器資

loadrunner 中的90%的請求響應時間

描述性統計與效能結果分析-LoadRunner,學到了平均相應時間和90%事務相應時間的關係,其中平均響應時間滿足了但是未必符合效能要求,有時候還要看90%事務相應時間。   具體參看以下內容:   LoadRunner中的90%響應時間是什麼意思?這個值在進行效能分析

loadrunner 壓力測試 平均響應時間20秒 100使用者併發 jquery.easyui.min.js 和jquery.js佔用時間最長

loadrunner 壓力測試 平均響應時間20秒  100使用者併發 jquery.easyui.min.js 和jquery.js佔用時間最長 很無奈。jquery.easyui.min.js和jquery.js 都是原始的。這個速度還說慢,沒有辦法,優化吧。 把

SylixOS 中斷響應時間測試

sylixos 中斷 綁核1.應用場景 在一些情況下,對於一些緊急的中斷任務,系統需要為其提供穩定可靠的中斷響應時間,但一般的中斷服務函數,它的響應時間可能會受到其他中斷向量的影響,延遲響應。在SylixOS中有兩種解方案。 1.提高該中斷向量優先級,打開中斷嵌套來確保緊急中斷的響應時間。

(C#)日誌接口請求響應時間

ide test isnull pty directory pps 請求方式 rri == 日誌接口響應時間,記錄接口請求信息,響應結果以及響應時間等。可以清楚的分析和了解接口現在。 如果一個一個地在接口下面做日誌,那不是我們想要的結果。所以,我們選擇做一個特性來控制接口要

網站或接口響應時間較長應該如何排查?

引用 ash 圖片 響應 ask java href 產生 ext 假如你的網站打開很久,什麽原因呢,先從最外層排查。瀏覽器按F12,看看Network哪個文件時間最長,這個是為了排查有可能css或者js插件引用了一些被國內墻住的地址,一直請求不到,所以時間很久。找到相關的

峰值QPS/QPS/PV/UV/服務器數量/並發數/吐吞量/響應時間計算公式

http segment 響應時間 服務器 系統 用戶 公式 成功 cond 原地址:https://segmentfault.com/q/1010000000503888 QPS:每秒查詢率(Query Per Second) ,每秒的響應請求數,也即是最大吞吐能力。Q

測服務響應時間的工具tcprstat

tcprstat 服務響應時間 tcprstat是percona開源的一款測試mysql服務響應時間的工具,不過對於任何運行在TCP協議上的響應時間,都可以用,只需要指定對應的端口即可。詳情可參考percona官方文檔https://www.percona.com/docs/wiki/tcprstat

優化頁面響應時間

負載 ajax請求 請求 一次 output 觸發 html 數據讀取 buffer緩沖區 大致方向: 1.頁面靜態化:適用於不是經常改動的頁面 偽靜態:將動態地址轉換為靜態地址 純靜態:分為局部純靜態、全部純靜態 buffer:緩沖區,一個內存地址空間,主要用於存儲數據

網站響應時間過長的原因及解決方法

網站打不開 網站程序 cas ron height 出口 javascrip 運算 access 遇到過類似問題,我認為有以下幾個原因: 1、網站服務器故障維修(這種情況只能等段

Jmeter性能測試中Tps圖與響應時間

ado jmeter 圖片 times col image per 技術分享 com jp@gc - Response Times Over Time顯示圖: jp@gc - Transactions per Second Jmeter性能測試中Tps圖與響應時間圖

QPS相關的概念收集(吞吐量(TPS)、QPS、並發數、響應時間(RT))

臺電腦 接受 邏輯 .cn 客戶 lan 頁面 增長 value 一、概念: 1、響應時間(RT) 響應時間是指系統對請求作出響應的時間。直觀上看,這個指標與人對軟件性能的主觀感受是非常一致的,因為它完整地記錄了整個計算機系統處理請求的時間。由於一個系統通常會提供許多