Posts Tagged ‘Quick Tip’

Decrease Indent in LoadRunner

Posted on May 8th 2012 by Joel Deutscher

To increase the indent on a section of code in VUGen, you can simply press the TAB key. This works as expected. To decrease the indent, the SHIFT + TAB keys work as they do in other programs such as MS Word and even VIM.

Hopefully everyone already knows this shortcut, though as its not documented in the menu, some people may have missed it.

An Alternative to System Info Wallpaper

Posted on December 21st 2011 by Joel Deutscher

RainmeterI have setup many machines to control and generate load. My initial experiences was with LINUX based systems, then as the tools progressed, the operating systems regressed onto the Windows platform. It seemed that back in the days of KVM’s, setting a new background colour for each machine was the way to tell them apart. Next came the system information imprinted on a wallpaper with tools like BgInfo from SysInternals. Unfortunately for this approach, a majority of RDP clients are setup to remove wallpapers (and should be if they aren’t). So in 2011 do we have a better way of displaying machine information on the desktop?
Continue Reading…

Quick Tip – LoadRunner Download Filters and Proxy Servers

Posted on May 24th 2011 by Joel Deutscher

A previously mentioned the move from a download filters black list to a white list to avoid hitting servers outside of our testing scope.

LoadRunner Download Filters

One interesting outcome of this change was a nasty C compile error.

Error: C interpreter run time error: Action.c (39):  Error -- memory violation : Exception ACCESS_VIOLATION received.

As it turns out, as we were using a proxy auto-config (PAC) file and this error occurs if your download filters are set to block your pac files. Luckily, LoadRunner does report that the PAC file was “Not downloaded due to a filter”, yet on the very next line reports that it was “downloaded and evaluated successfully”

Starting to download the proxy automatic configuration script, URL=""  	[MsgId: MMSG-27097]
Warning -26554: Not downloaded due to a filter, URL=""  	[MsgId: MWAR-26554]
Proxy automatic configuration script (URL="") downloaded and evaluated successfully  	[MsgId: MMSG-27096]

Surely if iframes are considered a critical resource, then the PAC file should cause an error and not just a warning, especially when it causes such a poorly handled memory violation error.

Luckily adding the pac file location to your download filters include list fixes this problem.

LoadRunner and iframes

Posted on May 24th 2011 by Joel Deutscher

After a recent application update, I noticed that all of our scripts started to fail. It turns out that the AUT now included a piece of tracking code, and our load generators did not resolve the domain name. The error message that came up was:

Error -26627: HTTP Status-Code=404 (Not Found) for ""  	[MsgId: MERR-26627]

So why would a 404 cause an error and not just a warning? Turns out that iframes are treated as a critical resource. By default, images, scripts, css are all treated as non-critical resources resulting in a warning only, however iframes are considered to be critical and hence cause an error. It makes sense for iframes to be a critical resource… in 1999 when the virtual mall was a good idea, yet in 2011, iframes are used for tracking services only. Rants aside, I could find the option to treat images, scripts and css as critical (pictured below), however I could not find the option to treat iframes as non-critical.

non-critical resource errors as warnings

By turning this option off, all 404’ed resources are treated as errors as well, as you can see in the following output log

Found resource "http://localhost/notfound.css" in HTML "http://localhost/iframe.html"  	[MsgId: MMSG-26659]
Found resource "http://localhost/notfound.js" in HTML "http://localhost/iframe.html"  	[MsgId: MMSG-26659]
Found resource "http://localhost/notfound.png" in HTML "http://localhost/iframe.html"  	[MsgId: MMSG-26659]
Detected non-resource "http://localhost/notfound-iframe.html" in "http://localhost/iframe.html"  	[MsgId: MMSG-26574]
Found resource "http://localhost/notfound-object.html" in HTML "http://localhost/iframe.html"  	[MsgId: MMSG-26659]
Error -26627: HTTP Status-Code=404 (Not Found) for "http://localhost/notfound.js"  	[MsgId: MERR-26627]
Error -26627: HTTP Status-Code=404 (Not Found) for "http://localhost/notfound.css"  	[MsgId: MERR-26627]
Error -26627: HTTP Status-Code=404 (Not Found) for "http://localhost/notfound.png"  	[MsgId: MERR-26627]
Error -26627: HTTP Status-Code=404 (Not Found) for "http://localhost/notfound-iframe.html"  	[MsgId: MERR-26627]
Error -26627: HTTP Status-Code=404 (Not Found) for "http://localhost/notfound-object.html"  	[MsgId: MERR-26627]
web_url("web_url") highest severity level was "ERROR", 1627 body bytes, 1438 header bytes  	[MsgId: MMSG-26388]

So back to the problem, a new domain that I needed to block had surfaced and if the domain name resolved, then it would have been included in the tests without my knowledge. While there are two schools of thought here, in the particular testing that I was doing, the customer did not want their tracking sites being hit from the performance tests, it was time to change approach and move to the include only list.

Why was this important? Well now I don’t have to catch every new tracking feature in order to block it, and my ever expanding list of blocked hostnames was now a thing of the past and everything was coming up Milhouse.

My test HTML page is as follows for anyone who is interested.


Testing IFRAME

Quick Tip – Fixing A Locked LoadRunner Results Directory

Posted on March 9th 2011 by Joel Deutscher

Everynow and then, Vugen will have a little episode and decide that its default results directory is locked, and you will be presented with an friendly dialog box like the one below.

The result directory is locked

If you have ever wondered what is going on, it turns out the culprit is mmdrv.exe. This executable is the Multithreaded Driver Command Line application that is used to simulate virtual users, and killing all instances from the task manager will remove any locks on your results directory, and you can go back to normal vugenning.

While most of us don’t mind using multiple directories, it seems that even in Vugen 11, the replay log window will always show the log of the first results directory after playback. This can be very confusing when debugging scripts.

This exe can also be used manually to execute vuser scripts from the command line. This can be handy for environment smoke tests. I will write more about some alternate uses for mmdrv.exe in a later post.