或者html
增長用戶數的方法web
一:僅對單個場景增長用戶數json
二:同時對多個場景增長用戶數tomcat
第一步:服務器
第二步:網絡
Action()併發
{性能
int nHttpRetCode;測試
web_reg_save_param("ResponseBody", "LB=", "RB=", "Search=Body", LAST);優化
web_save_header(RESPONSE,"ResponseHeader");
lr_start_transaction("activity");
web_custom_request("get_test",
"URL=http://192.168.1.249:8088/mobile2/activity/list.json?resultType=0&userType=3",
"Method=GET",
"Resource=0",
"Referer=",
"Mode=HTTP",
"EncType=text/html;charset=UTF-8",
"Body=",
LAST);
lr_end_transaction("activity", LR_PASS);
//打印返回信息
lr_output_message("# 響應頭信息:\n %s", lr_eval_string("{ResponseHeader}"));
//lr_output_message("# 響應原始內容體:\n %s", lr_eval_string("{ResponseBody}"));
lr_convert_string_encoding(lr_eval_string("{ResponseBody}"),LR_ENC_UTF8 ,LR_ENC_SYSTEM_LOCALE,"ResponseBodyUTF8");
lr_output_message("# 響應解碼後內容體:\n %s", lr_eval_string("{ResponseBodyUTF8}"));
//獲取服務器http響應碼
nHttpRetCode = web_get_int_property(HTTP_INFO_RETURN_CODE);
if(nHttpRetCode == 200)
{ lr_output_message("Success!"); }
else
{ lr_output_message("Failed! "); }
return 0;
}
關注:
Transaction: Transaction Name 事務名稱
Minimum 最小值
Average 平均值
Maximum 最大值
Std. Deviation 標準方差值
90 Percent 90% 響應時間
報告講解:
一、90 Percent響應時間:表示該組中90%的用戶都能在該時間內響應(完成該操做) 90 Percent 表示90%的用戶在 0.xxx 秒內完成操做 能夠經過Properties中 Percentile 90 能夠修改 -> Additional Settings -> Transaction Percentile 若改成80,表示80%的用戶。 再改回90%
二、一個事務,100用戶執行,其中一個用戶執行時間1000秒,其餘99%的用戶響應時間爲0.001秒。 則該狀況下90% 和 平均響應時間 哪一個更準確? 90 Percent
三、標準方差值:越小越好。越趨近於0,表示全部用戶執行該事務的響應時間越接近,表示系統越穩定。
(數學中知識)
Mininum Average Maximum Std.Deviation
0.203 0.313 0.404 0.095
說明前面幾個值比較接近,比較穩定。
四、網絡帶寬充足的狀況下,當吞吐量(Throughput)隨着點擊率(Hits per second)的升高而升高,說明AUT的服務器處理能力充足。
就會彈出了下拉菜單中進行選擇爲」new report「選項。
而後就會在new report中進行填寫爲general、format、content進行在其中內容根據的須要進行填寫,而後進行點擊generate。
而後就會彈出了一個word的文檔的格式選項。進行對當前的word文檔進行保存到本地的位置中,進行點擊菜單中的「save」的選項。
彈出了一個下拉的菜單中進行選擇爲「Microsoft word 2007 file」的選項。
而後就會彈出了export settings的選項框,能夠直接點擊OK。
進行選擇爲本地電腦的報告位置。
word能夠在本地電腦中找到該文件的報告,說明的是文件導出成功的。
生成html形式報告
1. LoadRunner測試結果分析的第一步應該是查看分析綜述(Analysis Summary),其包括統計綜述(Statistics Summary)、事務綜述(Transaction Summary)、HTTP 響應綜述(HTTP Responses Summary)三部分。在統計綜述中查看Total Errors的數量,HTTP 響應綜述中查看HTTP 404數量,若數值相對較大(HTTP 404則相對於HTTP 200),則說明系統測試中出錯較多,系統系能有問題;另外查看事務的平均響應時間和其90%的事務平均響應時間,若時間過長,超過測試計劃中的要求值,則說明系統的性能不知足咱們的要求。
2. 第二步對LoadRunner測試結果圖進行分析,首先對事務綜述(Transaction Summary)進行分析,該圖能夠直觀地看出在測試時間內事務的成功與失敗狀況,因此比第一步更容易判斷出被測系統運行是否正常。
3. 接着分析事務平均響應時間(Average Transaciton Response Time),若事務平均響應時間曲線趨高,則說明被測系統處理事務的速度開始逐漸變慢,即被測系統隨着運行時間的變化,總體性能不斷降低。當系統性能存在問題時,該曲線的走向通常表現爲開始緩慢上升,而後趨於平穩,最後緩慢降低。緣由是:被測系統處理事務能力降低,事務平均響應時間變長,在曲線上表現爲緩慢上升;而併發事務達到必定數量時,被測系統沒法處理多餘的事務,此時曲線變現爲趨於平穩;當一段時間後,事務不斷被處理,其數量減小,在曲線上表現爲降低。若是被測系統沒有等待機制,那麼事務響應時間會愈來愈長,最後系統崩潰。
4. 再分析每秒經過事務數(Transactions per Second/TPS),該曲線表示被測系統在運行的任意時刻,每一個事務經過、失敗的狀況,其是考查系統性能的一個重要參數。若隨着壓力的增長,曲線若是開始變化緩慢或有平穩的趨勢,則有多是服務器開始出現瓶頸。
[5]. 分析每秒經過事務總數(Total Transactions per Second),該曲線顯示在任意時刻被測系統經過的事務總數、失敗的事務總數。該曲線走向和TPS曲線走向一致。
[6]. 事務性能摘要(Transaction Performance Sunmmary)該曲線表示被測系統中全部事務的最小、最大和平均事務響應時間。
[7]. 事務在負載狀況下的響應時間(Transaction Response Time Under Load),該曲線表示在不一樣數量的虛擬用戶狀況下的事務響應時間狀況。該圖對分析具備漸變負載的測試場景比較有用。
[8]. 事務響應時間(百分比)(Transaction Response Time(Percentile)),該曲線能夠容易地分析出在給定的響應時間範圍內事務量的百分比重。
[9]. 事務響應時間(分佈)(Transaction Response Time(Distribution)),該圖能夠容易地分析出在給定響應時間範圍內的事務量狀況。
其實,若並非十分詳細地分析測試結果,第4步與第5步選其一分析,第6步、第7步、第8步爲可選項,由於在第1步就在必定程度上分析了,而第9步又與第8步功能相識。LoadRunner生成測試結果圖在很大的程度上具備必定的重複性,只不過是在不一樣狀況下的具體顯示。
(1)Tomcat conf文件夾下的server.xml
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
URIEncoding="UTF-8"
enableLookups="false"
disableUploadTimeout="true"
acceptCount="500"
maxThreads="500"
seURIValidationHack="false"
redirectPort="8443" />
(2)tomcat bin目錄catalina.sh增長
JAVA_OPTS='-server -Xms1024m -Xmx1024m'