Testing asynchronous business processes with LoadRunner

In the early days of the World Wide Web, web applications communicated using conversations that had a synchronous nature: the user interacts with an application that is presented in a web browser, the browser submits a request to the web server, the server sends a response, and the application in the browser is updated. 

 

However, synchronous applications have a number of limitations. One limitation involves the inability of the client to reflect events occurring at the server. This could be critical if, for example, the application in question displays stock prices or sport results and must present the updated info at all times. The answer to these limitations is asynchronous communication, whereby responses from the server arrive periodically or as a reaction to server-side events.

 

Many of today’s applications combine synchronous (user-initiated) and asynchronous (application-initiated) modes of communication between the client and the server. Usually the two occur in parallel (e.g. a user is navigating within the bank’s site, while at the same time stock updates keep pouring in), which makes it hard to accurately emulate such applications using traditional Vuser scripts. 

 

There are three primary types of asynchronous communication patterns: poll, long-poll and push:

 

  • Polling. The browser sends HTTP requests to the server at regular intervals, for example, every 5 seconds. The server responds with updates. This enables the system to update the application interface inside the browser.

Polling.png

 

  • Long polling. The client generates an HTTP request to a known address on the server. Whenever the server has an update, it responds with an HTTP response. Immediately after receiving the server response, the client issues another request.

Long Polling.png

 

  • Push. The client opens a connection with the server by sending a single HTTP request to a known address on the server. The server then sends a response that appears to never end, so that the client never closes the connection. Whenever necessary, the server sends a “sub message” update to the client over the open connection. The server may or may not terminate this connection. During the time the connection is open, if the server has no real update to send, it sends "ping" messages to the client to prevent the client from closing the connection for timeout reasons.

Push.png

 

How does LoadRunner handle these communication patterns?

 

First of all, before an asynchronous business process is recorded or regenerated in VuGen, we need to enable Async Scan. An Async Scan is a process wherein VuGen scans the generated script for instances of asynchronous communication and modifies it in order to allow such communications to be properly replayed. To enable Async Scan, go to the Recording Options dialog, select the “Code Generation” tab under the “General” folder and check the “Async Scan” checkbox. Also, by pressing the “Async Options” button, you’ll be able to get to the “Asynchronous Options” dialog, which will allow you to configure the recognition patterns of Async conversations used during the scan:

Options.png

 

Then record the process as usual.  After recording, the code will be generated and the Async Scan performed automatically. The results of the scan are then displayed in the Async tab of the Design Studio dialog, which is automatically presented at the end of the post-recording processing:

Design Studio.png

 

Each row of the table represents one “Async conversation” – a single instance of a push, poll or long poll asynchronous communication. Note that the “Type” column of the table says “Record” for all 3 conversations, which means that they have all been auto-detected during the scan following the recording. In addition, asynchronous conversations can be identified by invoking user-defined rules or manually by the user, but this is out of scope of this article.  You can consult Vugen’s help for more information.     Note also that unlike the “Correlation” tab of Design Studio (in which a user can decide which of the discovered correlations to apply to the script), Async tab is read-only: it allows reviewing the changes that VuGen has already made within the script. It is important to examine the information within this tab (including what is hidden in the “Details” section) very carefully, in order to make sure that the Async elements of the business process have been correctly recognized.

 

So, what changes has VuGen made to the script upon discovering asynchronicity?

 

  • VuGen inserts a web_reg_async_attributes step before the start of the asynchronous conversation. The web_reg_async_attributes step includes an ID for the asynchronous conversation, and the URL that is expected to start the asynchronous conversation. This ID is used by a subsequent web_stop_async step to indicate the end of the asynchronous conversation. The Pattern argument indicates the type of the asynchronous behavior: push, poll, or long-poll. The additional 3 arguments are the names of the callback functions, which will be invoked during the conversation. The callbacks are added to the AsyncCallbacks.c extra file, and we’ll discuss them in detail shortly.

Code1.png

 

  • For push conversations, VuGen inserts asynchronous API functions into the Vuser script, but does not remove any of the recorded code from the Vuser script. For polling and long-polling conversations, VuGen may remove steps or step parameters from the generated Vuser script (usually, these would be EXTRARES parameters). VuGen removes steps or step parameters in cases where the relevant URLs will be requested by running the inserted asynchronous functions - and not by running the original steps that have been removed.  

Note: Removed steps are not deleted – they are commented out. You can "uncomment" these steps if required.

 

  • When relevant, VuGen adds a web_stop_async step at the end of the asynchronous conversation. The web_stop_async step marks the end of the asynchronous conversation, as it was identified during recording.
  • The recording snapshots are updated by grouping the tasks in the asynchronous conversation under the step that started the conversation.

Now let’s discuss the callback functions, which are automatically added for each web_reg_async_attributes step. The available callbacks are:

  1. RequestCB – this callback is called before a request is sent.
  2. ResponseBodyBufferCB – this callback is called when there is content in the response body buffer and at the end of the response body. This callback is generated by VuGen automatically for push-type conversations, but is available for poll and long-poll conversations as well.
  3. ResponseCB – this callback is called after every response is received in the conversation.

The names of the callback functions start with the conversation ID of the asynchronous conversation. For example, the RequestCB callback for an asynchronous conversation with ID “LongPoll_0” will be LongPoll_0_RequestCB.

Here’s an example of an implementation of two of the callbacks:

code2.png

 

How do these changes affect the way the script is replayed?

When a web_reg_async_attributes step is encountered, the async conversation is registered. This means that during the execution of the following action step, a request is expected to be sent to the URL matching the URL attribute of the step.

If such a request is sent, it will automatically be handled asynchronously to the replay of the rest of the script. That is, other script steps may be executed before the relevant response is received.

The matching request will be handled according to the Pattern attribute:

  • For a Poll pattern, the request will be sent repeatedly. That is, after a response for a polling request is received, replay will wait for an interval matching the polling interval specified in the web_reg_async_attributes. After this interval has passed, another request will be sent, and so on.
  • For a Long Poll pattern, the request will be sent repeatedly. Another request will be sent as soon as a response for a polling request is received.
  • For a Push pattern, the response is expected to continue indefinitely (until it is terminated by either the server or the client).

For each request and response belonging to an asynchronous conversation, the callback functions declared in the web_reg_async_attributes step will be invoked automatically. This allows control over the sent requests, and gathering of data from the received responses.

  • The request callback is called before each request is sent. This allows you to modify the sent request (for example, it allows parameterizing the request URL and body).
  • The response callback is called after each response is received. This allows you to gather data from each received response in a polling or long polling conversation.
  • The response body buffer callback is called after each buffer is received during the response. This allows you to gather data in a push conversation.

These conversations will remain active until the end of the synchronous script if not terminated by the server or by user code, or until a web_stop_async step is called with the matching conversation ID.

 

Asynchronous scripting in VuGen is complex, and it is intended for advanced users. We have touched on some aspects of it, but to get the full picture, please consult the Async chapter of the VuGen user manual (VuGen > Working with VuGen > Design Studio > Async Studio).

 

Many thanks to Gal Shadeck from LoadRunner R&D for providing the material for this post.

 

Leave a comment in the box below to tell us how you're using asynchronous scripts to test your applications.

Comments
wilsonmar ‎04-14-2013 08:21 AM - edited ‎04-14-2013 08:22 AM

I'm happy to see deep dive info rather than just opinions.

 

People need to know this because some have switched to products which compete with LoadRunner due to previous lack of async support in LoadRunner. They need this memo!

puskarp | ‎04-14-2013 08:03 PM

Yes, thank you VERY much for posting this.  As a LR/PC veteran of many years, I'm blushing because I have not used this feature set yet.

For at least the past 7 years or so, I've developed similar workarounds via custom function calls that mimic the asynch types and then embedded calls to them  inside concurrent request blocks as the only known to me until now solution.

This will make it very much easier!

frederic b(anon) | ‎04-18-2013 03:08 PM

Is it a new thread in mmdrv.exe running the asynchronous conversation ?

Udhay | ‎04-18-2013 10:05 PM

Wonderful implementation.

We need to really see if the Call Back mechanism runs concurrently with the Synchronous script.  The question is if the call back function is receiving response and at the same time, the synchronous call is also receiving response - will the response time not be biassed?

How is Throughput handled in this case in terms of so many bytes per second?

Should we have a separate pipe/channel for measuring these responses?

| ‎04-21-2013 03:26 AM

The asynchronous conversation is still handled by the same thread.

 

The callback mechanism is simulated by one thread, so there could be no real "collisions" as Udhay describes.

This implementation may cause a small decrease in throughput, and may cause a small bias in measurements.

But it should also guarantee that you can run as many Vusers as possible on the same machine, since mdrv.exe and the operating system don't have to handle many more threads for each Vuser.

 

As for pipes/channels - yes, each Vuser will try to use more simultaneous sockets for the asynchronous conversations, so they should be measured accordingly.

 

If you already have scripts that you already generated using the Async feature,
or if you have scripts from older versions of LoadRunner for which you have already implemented your own asynchronous implementation, I would love to take a look at them.

It would help us greatly with further development of related features.

 

We greatly appreciate your feedback,

 

Oded Keret

LoadRunner R&D

HP Software

oded.keret@hp.com

Oded Hartmannn(anon) | ‎05-08-2013 01:05 AM

Great summary and information !!!

NaveenKumar N(anon) | ‎05-12-2013 09:11 AM

Excellent tutorials. Thanks to HP.

rpsd(anon) | ‎07-09-2013 05:50 AM

This information was very helpful but it does not provide a complete example of how to use the new asynchronous conversation feature in LoadRunner 11.5. I have also read the detailed information regarding this new feature in the Vugen User manual.  Both sets of documentation fail to provide a COMPLETE example which also includes

the IMPLEMENTATION details that are left out below in the LongPoll_0_RequestCB() and LongPoll_0_ResponseCB() callback functions. This complete example must include the web_util_set_request_url and the web_util_set_reqest_body() functions for the LongPoll_0_RequestCB callback as well as coding for the implementaion details for the LongPoll_0_ResponseCB callback. I realize that these implementation details will vary for each example, but the inclusion of these missing details is the only way to provide a complete example of the LoadRunner async conversation feature. It would be great if this example would refer to a website that is commonly available which uses the asynchronous conversation feature.

 

 

code2.png

 

 

Anandababu153(anon) | ‎02-03-2014 01:56 AM

I'm setting a flag in poll_1_ResponseCB() to determine wheather I need to loop this Async URL or to call "web_stop_async", but when the request fails at "HTTP-Time-Out" it prints "Deleting conversation with poll_1".

 

What happens when a async call faces "HTTP-Time-Out"? Does it follow a normal flow, or it will focefully stop the Async by calling "web_stop_async"?

 

How the script can be changed  NOT to call "web_stop_sync" call even after facing time out exception?

 

Tariq Ahmed(anon) | ‎02-19-2014 06:26 AM

Hello

 

 

i have one of my application developed in .net

 

 

i have used protocol advisar . which recognize the web HTTP/html  and silverlight protocols.

but i can not use both togather.   as i am using the Loadrunner11.52.

 

i have tryed many times with all the options. but could not record it.

 

actually i want to say that my applications  uses  both synchronous (user-initiated) and asynchronous (application-initiated) modes. while i am getting Failed on the Recording step.   we are using TCP binding in the application and my application supports only sliverlight5.1 version.    can any body help me the same case

test1230(anon) | ‎06-23-2014 03:53 AM

Hi,

 

I am working on an async request in loadrunner which is based on push technology. My question is, as it is being push model the request will be send to server one time. after that client will  keep on getting response from server. So one request and multiple response for the same. how do I simulate the same in loadrunner.

 

Can anyone worked on similar case?

 

thanks

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
About the Author
Malcolm is a functional architect, focusing on best practices and methodologies across the software development lifecycle.


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