[Original] How LoadRunner obtains the search response time for each keyword in the Parameter

When testing a search engine, we usually use a large number of search keywords. Sometimes it is necessary to know the response time of each keyword in the case of concurrent access, generally, if you do not process the script, you can obtain the response time of each keyword, but these times do not correspond to the corresponding keyword, so there is no great help for program tuning, here we will introduce a method to let you know the response time of each keyword under concurrent access.
The solution is to define the search operation as a transaction and replace the transaction name with the parameter value, so that you can know the response time of the keyword from the test results. Example:
# Include "web_api.h"
Action ()
{
Lr_start_transaction (lr_eval_string ("{searchparam }"));
Web_url ("S ",
"Url = http://www.baidu.com/s? WD = {searchparam }",
"Resource = 0 ",
"Reccontenttype = text/html ",
"Referer = ",
"Snapshot = t1.inf ",
"Mode = http ",
Last );
Lr_end_transaction (lr_eval_string ("{searchparam}"), lr_auto );
Return 0;
}
In this way, you can see the time used by each keyword in the transaction monitoring graph when running in the scenario.
The disadvantage of this method is that when there are many keywords, the number of rows in the monitor will increase, which may cause the Controller to not display.
Another method is as follows:
# Include "web_api.h"
Action (){
Float trans_time;
Lr_start_transaction ("sousuo ");
Web_url ("S ",
"Url = http://www.baidu.com/s? WD = {searchparam }",
"Resource = 0 ",
"Reccontenttype = text/html ",
"Referer = ",
"Snapshot = t1.inf ",
"Mode = http ",
Last );
Trans_time = lr_get_transaction_duration ("sousuo") * 1000;
Lr_output_message ("searchparam: % s, duration: % FMS", lr_eval_string ("{searchparam}"), trans_time );
Lr_end_transaction ("sousuo", lr_auto );
Return 0;
}
Generally, this method is better. You can replace the lr_output_message function with a custom function and write the result to a result file. Note that the written file should be named by vuser ID, this ensures that only one process is reading and writing this file (in this way, different users read and write different files, otherwise, if multiple users write data to the same file concurrently, the access and sharing violation may occur to the same file. The vuser ID obtained function is lr_whoami ). In addition, it should be noted that the transaction time obtained here may be less time than the transaction time obtained through lr_start_transaction and lr_end_transaction. This is caused by the test tool itself and can be ignored.
At the same time, if you want to know which keyword search result is incorrect during the Query Process, you can also add verification points and code to filter out keywords that have been searched for more than a certain period of time.