In a previous post I explained how to add network conditions to a LoadRunner scenario, answering the question, “How will this application perform in a remote site?” The results from running a LoadRunner test with network conditions will highlight transactions that perform well under network conditions as well as pinpoint transactions that will degrade in performance under network conditions.
In this post I will show you how to generate analysis in less than three minutes that addresses the question that naturally follows. “Why does this transaction perform well locally, but slows down under network conditions?”
This analysis can be generated by installing VE Analyzer on the “remote” load generator and configuring it with the packet analysis settings (reminder: the “remote” load generator is any load generator that has the VE Desktop Professional WAN Emulation client installed on it. This WAN Emulation client enables us to simulate remote network conditions from a local load generator in the lab. Hence the double quotes in “remote” since the generator isn’t physically remote but is simulated to behave that way)
Follow these steps to setup the analysis on the “remote” load generator:
In the LoadRunner Controller Design screen click on the Load Generators button
Select the “remote” load generator
Click on details and select the WAN Emulation Tab:
Check the “Enable WAN Emulation” check box (if not already selected) and click on “WAN Emulation Settings”
See the previous post on how to setup the WAN Emulation parameters in the following screen.
Click on the additional settings button
First check the “Capture Packets” check box, this enables the packet capturing agent on the VE Desktop Client on the LoadGenerator. I recommend assigning at least 100 MB of buffer space for the capture so at least one iteration of the script will be captured.
For web based applications, select HTTP in the “Automatically run post-test analysis” option, for other applications select either TCP or UDP analysis.
Finally, select a folder on the load generator for automatically saving the test results. It is important to re-iterate that this folder is on the “remote” load generator, not on the LoadRunner Controller.
It is recommended to setup only 1 virtual user to run from this “remote” generator, so the analysis will focus on a single instance of the user. If load is needed as part of the scenario, it should be generated from a second load generator, in this case the analysis will show results of the marginal user.
Adding the analysis capabilities in this example doesn’t require any changes to the script and can be applied to the same scenario we presented in the previous post. Running this test results in an analysis report that is generated on the LoadGenerator. This report can be accessed from the VE Reperter that is installed on the “remote” load generator.
VE Reporter stores the reports based on the test names and the test run dates, so we are looking for the last test run for our test.
Once the report opens we are mainly interested in 4 reports:
The Application Efficiency Report shows us how chatty the application is (application chattiness is directly related to response time slow downs due to network latency) as well as how long it took to download various resources from the server. In this example, we see a resource that took 9 seconds to download, explaining why the entire action took 11 seconds for a remote user Vs, 0.6 seconds for a local user.
The Application Efficiency Report highlights a resource that took 9.2 seconds to download
The second report is the Client Network Server Breakdown that shows how much time the transaction spent on the client, network and server.
A Client Network Server Breakdown Report
The 3rd report is the Bandwidth Analysis which shows how much bandwidth was used by this single application user.
Finally, for a real deep dive we can use the Bounce Diagram that displays the entire communication between the client and the server as well as the delta times between consecutive packets, high delta times can point out to blocking events within the transaction.
The Bounce Diagram shows deep packet analysis data on the transaction
In summary, in less than 3 minutes we can generate the above reports on any transaction that seems to be performing poorly over the Wide Area Network. This information can help the developers and network engineers to fine-tune the application and the network to improve the end user experience.
Feel free to suggest additional topics you would like to see covered in this series of posts.
Best,
Amichai
June 15th, 2009 at 6:20 am
great blog !!,VE make ease the effort to pin point the network bottlenecks. i have few questions based on the reports generated by VE Reporter.
1.What is ideal value for delta time or what is the delta time value limit in an efficient/smooth network communication?
2.what should be the ideal Bandwidth usage?
3.In Client Network Server Breakdown Report, what is Ideal client;network:server time ratio?
June 25th, 2009 at 9:54 am
Hi Vijesh,
1. The delta time represents the time passed between 2 consecutive packets in the bounce diagram. The direction of the arrows are of importance here: for 2 packets coming from the client any delta time represents client rendering time/processing time, for 2 packets coming from the server the delta time represents server processing time, for 2 packets that are changing direction (app turn) the delta time represents the blocking time of the network delay. In Synchronous applications that delta time would be slightly less than or equal to the network latency (in most cases) in asynchronous applications that delta time may be very small as the participating parties are not blocked by the network delay and can keep sending messages across even if the previous message didn’t complete its processing.
2. There is no ideal bandwidth usage, how much bandwidth a transaction should use is a function of many parameters but mainly it depends on the size of the data that it needs to display. There are a few guidelines though: 1. Download only what is needed for rendering (deferred loading). 2. Download only the code you need to execute the given transaction (code modulization). 3. If multiple components are needed (e.g. in a web page) download them in parallel. 4. Minify code, compress html, compress images.
3. The client network server report shows the time spent by each tier, again there is no right or wrong, however the insight that you can gain from that report includes:
a. Where is the bottleneck, is this transaction server bound, client bound or too chatty and hence network bound.
b. Where should the tuning efforts focus on, the client, server or messaging code.
c. Will a stronger server or a stronger client improce performance (if the transaction is not server bound then a stronger server will do very little).
Hope this helps,
Best,
Amichai