Loadrunner Analysis Traffic Feature

Vugen Script Generated from a Trace File

Where the application front end cannot be recorded, Vugen can analyse server traffic files to create automated test scripts using the Analyze Traffic feature. This will create what is known as a Server Traffic Script.


Analyze? I prefer analyse. Please excuse my deliberate misspelling.


The Java protocol is a case in point. Loadrunner Java scripts for load testing can only be played back. They cannot be recorded. The question is, will the analyse traffic feature help performance tester to develop a working script?


As usual, the Vugen user guide makes it sound easy. Step 1: generate a capture file. Is this as easy as it sounds, or is it a bit more complicated?


Apparently the capture file is a trace that contains a log of TCP network traffic. I hate the term ‘sniffer application’, it is meaningless. A dump of the network traffic can be obtained by a network tracing tool. My favourite tool is Ethereal. In mid 2006 after a long and bitter dispute involving the trademark, Ethereal was re-named Wireshark, which in my opinion is a much better name any way. Wireshark is a free tool and I know lots of network people who use this tool on a regular basis. Take some time to get to know Wireshark, with a bit a familiarisation you can figure out how to generate a network trace.


If you do not want to use Wireshark, then Vugen has a capture facility that can be used. To do this, a command is issued (from the command line). There are separate commands for different platforms, e.g. for windows, the command is lrtcpdump.exe whereas for HP’s version of Unix, the command is lrtcpdump.hp9.


Now that we have a capture file all we have to do is generate a Loadrunner script. It is at this point in the process that I had very little confidence that the capture file would be valid. Still, all you can do is give it a go. As I started up Vugen the instructions indicated that after processing the capture file I would have either a web services or web soap functions generated. So, after all that effort, I realise that this is just another feature aimed at web applications. Sorry Java or some other bespoke application, you will have to wait another day.


Still, I can press on and evaluate how it works for an un-recordable web based application.


So, quickly finding a web application (www.afcwimbledon.co.uk), I captured a trace file and saved it away somewhere safe.


Starting Vugen,

  1. I created a new script selecting single protocol for webservices. The analyse traffic button was easy to spot on the main menu bar.

  2. Selecting analyse traffic, I was presented with a new window that requested WSDL’s.

  3. I did not have any of those, so I just selected next and was presented with a screen that indicated ‘finish’ rather than ‘next’ which was a good sign.

The first problem. Loadrunner expected my capture file to have an extension of cap e.g. the file neame would look like capturefile.cap. Wireshark produced a capture file with a pcap file extension. With a sense of foreboding, I selected the Wireshark trace anyway.


The second problem. Did I have incoming traffic or outgoing traffic? Well, I figured that if I was sending a request and receiving a response I probably had both. Unfortunately, the incoming and out going traffic options are mutually exclusive, you have to choose one or other. In the end I tried both, neither produced satisfactory results.


Vugen accepted the capture file, populated a recording log and a generation log, but failed to produce a single statement of code.


My instincts were correct. Despite capturing what looked like a valid capture file, against a website, a Vugen script was not generated.