Time processing in LoadRunner--things time, time spent, etc.

1. Response Time

A transaction is a set of operations required by a user to do one or more services on the client, which can be used to mark the operations required to complete the business, and on the other hand the transaction can be utilized to count the response time of the user operation. The transaction response time is calculated by logging the user request's start time and the server's return content to the client time to calculate the user action response time, as shown in Figure 1.

The response time here does not include client GUI time (such as the time spent by the browser explaining the page). It says that response time is the time difference between a user request and a server return, so it's enough to get it.
For example: Now there is a running race. When the game is finished, you can get each athlete to run the entire race to spend time, now need to analyze who the starting good, who sprint good, can analyze it out. The answer is no, although getting the most important response time to complete the game, it has little effect on analysis and optimization because only the results are known and the process is not known. Running time is composed of starting, Midway, Sprint and other time, if you want to analyze optimization, you must first understand the time and speed of each stage and the pros and cons of each athlete.
For software, the system response time through transactions is also composed of a lot of parts, generally speaking, response time is composed of three parts: Network time, server processing time and network delay. Let's take a look at what paths a client needs to go through when making a request to the server, as shown in Figure 2.

1. Network time
The client makes a request first over the network to the Web server (consumes time N1), and then the Web server sends the processed request to the app server (which consumes time N2), and the app server sends the action data instruction to the database (N3); The database server sends the query result data back to the app server (consumes time N4); The app server will send the processed page to Web server (time consuming is N5); last web The server forwards the HTML to the client (consumes time N6). NX Here is the time spent on network transmissions and does not calculate the time it takes for the business to process.
2. Server processing Time
Another aspect is to consider the time required for each server to process wt, AT, and DT. 3. Network Latency
In addition to the above two kinds of time overhead, also consider the problem of network latency. So the final response time is composed of:
Response time = Network delay time + WT+AT+DT + (N1+N2+N3) + (N4+N5+N6) + Wt+at+dt It is also simple to think that the response time is comprised of both network overhead (front end) and server overhead (back end), as shown in Figure 3.

So what is the time spent on it? The factors that affect the network generally include the following: 1.

Front-end network DNS Lookup

Time to connect

Time to first buffer

Network time

Download time

SSL handshake

FTP Authentication

Client time

Error Time Network delay

2. Back-end Services

Web Server

Servlet time

Method time

Static dynamic compression

APP Server

EJB time

Method time

JNDI Lookup

Database Server

JDBC time

Connect time

Execute time

The composition of the response time is very complex and it is quite difficult to locate the specific code level when the performance problem arises.
LoadRunner can only make a network-level analysis of the request and the content returned by the server, which means that LoadRunner can analyze the time of the client to the WWW server N1 and the WWW server to return to the customer's time N6. These times are mainly related to network speed, can be explained by a LoadRunner name, called Web Page breakdown.
That is, Vugen can analyze only a portion of the time between the client and the Web server, and then only a sum of time from the Web server to the app server to database server.
2. Transaction time
The time of a transaction is the duration, and the transaction will completely record the time difference between the start of the transaction and the end of the transactions, so the time of the transaction can truly reflect the business operation. No, it's like a man with his hand on a stopwatch to record sprint time, the resulting time is not completely accurate, there are observed errors and operating errors, for a transaction time, generally consists of four parts, as shown in Figure 4

In addition to the time wasted by the script itself, the time it takes to process an external interface, such as the C language, will also affect the time of the transaction, and this time LoadRunner cannot be processed, in which case the third-party time overhead is artificially calculated and the time of the overhead is recorded in wasted In time.
Run the following code:

Action ()
{   
    int i;  
    int baseiter = +;
    Char dude[1000];   
    merc_timer_handle_t timer;   Examine the total elapsed time of the action, which is equivalent to declaring a timer 
    
    //start transaction  transaction begins 
	  Lr_start_transaction ( "Demo"); 
	    
    Timer=lr_start_timer ();  The timer starts for
     (i=0;i<=baseiter*1000;i++) {  
           sprintf (dude, "This is the the-the-the-waste time in a script =
           %d", i);  
    Wastetime=lr_end_timer (timer);//elapsed time, by calling the function Lr_end_timer provided by LoadRunner to stop the timing (lr_end_ Timer The entry of this function is a timer), the time unit is milliseconds

    lr_wasted_time (wastetime*1000),//convert wastetime to seconds and count into the
     
    //stop transaction of LR  end
	  of transaction lr_end_transaction ("Demo", lr_pass);
	  
	  return 0;
}

Wasted time, when running in the scene, the response times of the transaction are automatically deducted wasted 16.    Lr_end_transaction ("Demo", Lr_auto);    . return 0; 18.}
where Lr_start_timer () is a loadrunner time counter, which corresponds to Lr_end_timer () and can return the difference between the two functions.
After you run the script, wait for a while before the script finishes running, you can see the following logs.

ACTION.C: Notify:transaction "Demo" started. 

ACTION.C: Wasted Time is 85.860000  
action.c: notify:transaction ' Demo ' ended with  

As you can see from the above log, the time spent in this 1000-time C operation when Vugen runs the script will be counted in transaction time, causing transaction to grow longer. When the elapsed time is added to wasted times through the Lr_start_timer () Timer function, the script can correctly calculate the time of the transaction and the wasted time of the transaction. When running in the scene, the response time of the transaction is automatically deducted from wasted.
In order to ensure that the response time is correct, it is necessary to deduct the time consumed by itself when the script is run, to avoid non-request processing in the transaction, and if not avoided, use the lr_wasted_time () function to deduct the extra time overhead.

For example, a script like this:

merc_timer_handle_t timer; Variable declaration  
 lr_start_transaction ("Demo");   
 Timer=lr_start_timer ();  
 Lr_load_dll ("Getkey.dll");  
 Lr_save_string (Getrandkey (), "key");  
 Get the key  
 Wastetime=lr_end_timer (timer) by calling the DLL; 
 Lr_wasted_time (wastetime*1000);  
Lr_end_transaction ("Demo", Lr_auto);

Calculating the key is time consuming, so you can use the timer variable to record the time of the calculation and deduct the time from the entire transaction.
Do not use Lr_wasted_time () overrides directly when calculating wasted time, and forget to add the LoadRunner function to the script. The Lr_get_transaction_wasted_time () function can be used to obtain the wasted time of the transaction itself, which accumulates the wasted of the third-party statistic and overwrites it by the Lr_wasted_time () function.
3. Manual Transactions
Before using Lr_auto to determine the state of a transaction, now make a script to see how LoadRunner's transactions are automatically judged.
Record a user's script in a forum, add a transaction start and end flag at the submit registration form, and then play back the script. The result of the transaction is pass or fail. Although the replay script registration user is unsuccessful (the user already exists), the transaction is completed in the pass state, and the transaction duration is found to be short. Normally, it takes 2 seconds to register a user to refresh the home page, now only 0.3 seconds. This is because when the server determines that the user already exists, there is no data to insert and wait 1 seconds to refresh the first page of the operation, but directly return to the error prompt. This 0.3 seconds is the time the system handles the error rather than the time it takes to register the user.
Lr_auto is also based on the return status of the server to determine whether the transaction is in the Lr_pass state or end in the Lr_fail state, as long as the server returned to the page, then the transaction will be considered the request successfully sent, the server understand the request also returned content, natural transaction is the pass state.

This is because the transaction automatically judges the error, resulting in the failure of the operation, but a response time is given, and the response time does not correctly reflect the actual time to do this, and ultimately affect the data obtained by the performance test.
Remember in the forum on a friend asked such questions, why the system in the user more and more cases, the response time is not increased anti-minus. This behavior is most likely the result of not using manual transactions.
In this case, it is necessary to manually determine the success of the operation, through the Web_reg_find () checkpoint function to check whether the page is returned correctly, and then through the rowcount parameter value to make the transaction state judgment, so that the intelligent judgment of the transaction results.
For example: The rowcount of the checkpoint function is stored in the parameter loginst, so the state of the transaction should be judged as follows:

Lr_start_transaction ("login");
Web_reg_find ("Search=body",   
        "Savecount=loginst",   
        "text= Login Failed", last   
        );   
Login Request  
If (Atoi (lr_eval_string ("{loginst}")) >=1))   
        lr_end_transaction ("login", lr_fail);   
Else  
         

Check to check the page after login is not the existence of "Login failed" Such content, if there is so loginst value is greater than or equal to 1, then the value of Loginst out and 1 to compare, if greater than 1 then is the login failure, otherwise is the login success.
A parameter cannot be compared with a value, so it is converted to a string by the lr_eval_string () function and then converted to an integer by the atoi () function, so that it can be compared with 1.
In most cases, a manual transaction is required for transactions to ensure the correctness of transactions and the validity of transaction time.
Study Questions
For the Discuz forum, how to do a valid user registration script through manual transactions and get accurate registration operation response time.
Business Analysis:
After registering the user, the "Welcome: Registered User Name" message appears on the system's page, and you can check if such content appears in the page returned after registration to determine if the registration transaction was successful.

By checking the page you can get the code that needs to be judged:
1. Welcome: <a class= "Dropmenu" id= "Viewpro" onmouseover= "ShowMenu (this.id)" >
So in the checkpoint function need to add this content, in order to better judge, also need to put the name of the registered user also added, and finally can get the following code:

Action ()
{
        web_url ("Sign Up",
            "URL = http: //192.168.0.200/register.aspx",
            "TargetFrame =",
            "Resource = 0",
            "RecContentType = text / html",
            "Referer = http: //192.168.0.200/",

            "Snapshot = t2.inf",
             "Mode = HTML",
             EXTRARES,
             "URL = / templates / default / images / check_error.gif", ENDITEM,
             "URL = / templates / default / images / check_right.gif", ENDITEM,
             "URL = / images / level / 3.gif", ENDITEM,
             LAST);
       
         lr_start_transaction ("reg");
       
         web_reg_find ("Search = Body",
             "SaveCount = regst",
             "Text = Welcome: <a class=\"dropmenu\" id=\"viewpro\" onmouseover= \"showMenu(this.id)\"> {username}",
             LAST);
       
         web_submit_data ("register.aspx",
             "Action = http: //192.168.0.200/register.aspx? Createuser = 1",
             "Method = POST",
             "TargetFrame =",
             "RecContentType = text / html",
                          "Referer = http: //192.168.0.200/register.aspx",
             "Snapshot = t11.inf",
             "Mode = HTML",
             ITEMDATA,
             "Name = username", "Value = {username}", ENDITEM,
             "Name = password", "Value = 112212", ENDITEM,
             "Name = password2", "Value = 112212", ENDITEM,
             "Name = email", "Value={username}@cloud.chen", ENDITEM,
             "Name = submit", "Value = create user", ENDITEM,
             "Name = question", "Value = 0", ENDITEM,
             "Name = answer", "Value =", ENDITEM,
             "Name = realname", "Value =", ENDITEM,
             "Name = idcard", "Value =", ENDITEM,
             "Name = mobile", "Value =", ENDITEM,
             "Name = phone", "Value =", ENDITEM,
             "Name = gender", "Value = 0", ENDITEM,
             "Name = nickname", "Value =", ENDITEM,
             "Name = bday_y", "Value =", ENDITEM,
             "Name = bday_m", "Value =", ENDITEM,
             "Name = bday_d", "Value =", ENDITEM,
             "Name = location", "Value =", ENDITEM,
             "Name = msn", "Value =", ENDITEM,
             "Name = yahoo", "Value =", ENDITEM,
             "Name = skype", "Value =", ENDITEM,
             "Name = icq", "Value =", ENDITEM,
             "Name = qq", "Value =", ENDITEM,
             "Name = homepage", "Value =", ENDITEM,
             "Name = bio", "Value =", ENDITEM,
             "Name = templateid", "Value = 0", ENDITEM,
             "Name = tpp", "Value = 0", ENDITEM,
             "Name = ppp", "Value = 0", ENDITEM,
             "Name = newpm", "Value = radiobutton", ENDITEM,
             "Name = pmsound", "Value = 1", ENDITEM,
             "Name = showemail", "Value = 1", ENDITEM,
             "Name = receivesetting", "Value = 2", ENDITEM,
             "Name = receivesetting", "Value = 4", ENDITEM,
             "Name = invisible", "Value = 0", ENDITEM,
             "Name = signature", "Value =", ENDITEM,
             "Name = sigstatus", "Value = 1", ENDITEM,
             LAST);
       
         if (atoi (lr_eval_string ("{regst}"))> = 1)
             lr_end_transaction ("reg", LR_PASS);
         else
             lr_end_transaction ("reg", LR_FAIL);
         return 0;
     } 

The {username} here is a parameter that holds the registered user name and sets the value method and information for the parameter in the parameter list.