Measuring asynchronous transaction time in LoadRunner

The idea for this post was provided by Leonid Pekel, from the LoadRunner R&D Team.

 

I wrote a post in April that described how to test asynchronous business processes with LoadRunner (if you haven’t read it recently, I recommend that you look at it once you have finished this one).  As a reminder, a synchronous conversation involves a virtual user (Vuser) submitting a request to a service, which processes the request and then sends a response.  While the request is being processed, the application waits for the response before being able to continue with other tasks.  The time for this transaction is typically measured and reported by surrounding the conversation with calls to lr_start_transaction and lr_end_transaction.

 

In an asynchronous conversation, the Vuser submits a request to a service, which processes the request. The difference here is that while the request is being processed, the Vuser is free to continue with other work.   But if you were to use lr_start_transaction and lr_end_transaction, an inaccurate transaction time will be reported, because it includes work done by the Vuser as well as the work done by the service.

 

For example, assume the Vuser executes custom code that includes lr_think_time steps during a push conversation.  In a synchronous conversation surrounded with lr_start_transaction and lr_end_transaction steps, this think time would be excluded from the transaction measurement.  But in the asynchronous conversation, the think time would be included.  The solution is to measure the asynchronous download duration with timer functions, and reporting it with an lr_set_transaction call, as follows:

 

  • Declare a timer:

     merc_timer_handle_t timer;

 

  • Start the timer inside the Request callback, as follows:

     int  Push_0_RequestCB()
     {
         //Enter your implementation for RequestCB() here.

         //Call web_util_set_request_url() here to modify request URL:
         //web_util_set_request_url("<request url>");

         //Call web_util_set_request_body() here to modify request body:
         //web_util_set_request_body("<request body>");


         timer = lr_start_timer();
         return WEB_ASYNC_CB_RC_OK;
     }

 

  • End the timer and report the transaction time (and other useful information, such as the size of the data sent by the service) inside the Response callback, as follows:

     int  Push_0_ResponseCB(

         const char *    aResponseHeadersStr,
         int                     aResponseHeadersLen,
         const char *    aResponseBodyStr,
         int                     aResponseBodyLen,
         int                     aHttpStatusCode)
     {
         //Enter your implementation for ResponseCB() here.

         //TODO - To make the script wait for a specific response, use web_sync in the relevant Action file.
         //See the Modifying Callbacks section in the VuGen user guide for more details.
         lr_user_data_point("Push data size",  aResponseBodyLen);
         lr_set_transaction("Push download time"lr_end_timer(timer), LR_PASS);

         return WEB_ASYNC_CB_RC_OK;
     }

 

 

Leave us a comment in the box below to share your insights into asynchronous transactions.

 

 

Thanks again to Leonid for the idea this post!

 

Labels: LoadRunner| testing
Comments
wilsonmar | ‎08-13-2013 07:45 AM

Where is WEB_ASYNC_CB_RC_OK defined, and what is its value?

‎08-13-2013 10:40 AM - edited ‎08-13-2013 10:41 AM

Hi wilsonmar,

 

WEB_ASYNC_CB_RC_OK is defined in web_api.h, and it's value is 0.

tgvamni | ‎05-05-2014 05:43 AM

Does this work for websocket protocol ? How is the correlation between a response and request done ? Is there a limit to the number of timers that can be created? With websockets, transaction throughput can be very high...

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Malcolm is a functional architect, focusing on best practices and methodologies across the software development lifecycle.
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.