Posts Tagged ‘Rant’

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 "http://tracking.headwired.com/track.asp"  	[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

Execute the 100% Load Test First

Posted on January 11th 2010 by Joel Deutscher

There has always been something about performance testing that has bugged me over the years. It’s the standard approach of ramping up the amount of load on each test execution cycle.

The typical order of executions for a performance test is:

  1. Smoke Test
  2. 25% Load
  3. 50% Load
  4. 75% Load
  5. 100% Load

The flaw, as I see it, lies in the order of execution. I think we an improve on this concept by aiming to ramp down instead. Continue Reading…