HaveComputerWillCode.Com

Welcome!
Life is a Non-Deterministic Finite State Automata
Automation ? (*pGeekiness)++ : Code /eneration;

July 29, 2010

Correlating ASP.NET Websites with Jmeter

Filed under: Performance,Testing — Tags: , — admin @ 9:14 am

I’ve been using Jmeter recently to stress test some ASP.NET Websites. Although originally designed to test the Apache Web Server itself, Jmeter is more than capable of testing ASP.NET on IIS too. As any good tester performance will tell you, and as anyone that occasionally does performance testing like myself will quickly find out, it is important to correlate data correctly between requests. When you manually purchase something on a website built with ASP.NET, for example, it is highly likely there is a field called VIEWSTATE:

    … id=”__VIEWSTATE” value=”fkdiorulfnvnsldjtrnvlsedlkrjnlkednvld….sdfosdkldllgfdf”

Although it looks like the personification of ‘Monkeys with Typewriters’, it means something. And, depending on the way the Server is set up, sending back inconsistent VIEWSTATE and EVENTVALIDATION fields will result in a Server Error 500. Not the most helpful of error messages when you are Black Box Testing.

More information on this and the hows and whys can be found here.

Whenever you navigate through a form-based system developed using ASP.NET, it is likely you will get back a new VIEWSTATE and/or EVENTVALIDATION on each page. The implication of this is that when you automate the tests, you need to extract the VIEWSTATE from the page you just got and then insert it into the next HTTP POST request. This is called CORRELATION.

To correlate information in Jmeter, the first thing you need to do after a HTTP Sample Request is execute a Regular Expression Post-Processor to extract the VIEWSTATE into a local variable. It might look something like this:

In the subsequent HTTP POST Request, you need to insert your variable name in place of the actual value:

Unfortunately, the whole experience is a bit painful in Jmeter because there is no automatic correlation (or none that I could find). So you end up extracting the information after every step as you can see above.

That’s inconvenient and error prone when you have a long sequence of operations and/or a lot of correlation to perform. To simplify the sequence, I tend to wrap the individual steps up in an Interleaved Controller which is itself wrapped up in a Loop Controller like this:

By structuring your tests as above, the Interleaved Controller executes the next Sampler (Navigate To Home Page; Do Something; Do Something Else) on each iteration of the loop. By putting the correlation extraction logic outside of the Interleaved Controller as shown above, but within the loop, it will be executed on every loop iteration. A word of warning with this though – the Interleaved Controller sometimes behaves in weird and wacky ways when it contains anything other than a Simple Controller!

As Jmeter lacks a ‘Debugger’ to help you step through your scripts and track your variables, I tend to develop my scripts as above with a Pre and Post Debug Sampler wrapping the Interleaved Controller so they get executed every step. Tchau!

July 25, 2010

Partially fetching files using Accept-Range and Range in Jmeter

Filed under: Performance,Testing — Tags: , — admin @ 7:34 am

(and how to avoid the Out Of Memory Heap Crash Dump in Jmeter)

We had a situation with Jmeter recently where we needed to stress test a remote server by downloading lots of huge files – and I mean: in the hundreds of megabytes each. In parallel. And ideally using as few machines as possible. The network pipe was fat so that was not going to be the limiting factor. But Jmeter kept crash-dumping with Out Of Memory errors… I managed to avoid crash dump analysis for six years at my last job using all kinds of creative excuses (and long may it continue!) so we looked at causes closer to home. Jmeter has an annoying habit of holding onto data even when you don’t need it so the memory used to hold parts of the large files as they were retrieved would accumulate and never be garbage collected… you get the idea.

A small tweak to the Jmeter configuration file and increasing the heap size to 1G maximum helped:

rem See the unix startup file for the rationale of the following parameters,
rem including some tuning recommendations
set HEAP=-Xms512m -Xmx1G
set NEW=-XX:NewSize=128m -XX:MaxNewSize=128m

… but the breaking point had just been moved further away.

The way around this, and something we needed to test anyway, was to fetch ‘slices’ or ‘ranges’ of files from the server instead of the whole thing. Some servers (not all) support the ‘Accept-Range’ HTTP Header that will bring back just part of a file hosted on it (it’s the same way Suspend / Resume works with some Download Managers). If you’ve put a server in place and configured it, you will know if it supports it. If not, just set up a HTTP Sampler that downloads any files from the server and look at the Sampler Result in a Tree View Listener:

If you can see something like Accept-Range: bytes in there, then you’re in luck and the server supports downloading parts (ranges) of files. With that in mind, all you need to do to bring down part of a file is to add the following Header to your HTTP Sampler and specify your byte range:

When you run that code, you will now see a response showing the byte range fetched. Notice the Response code is now 206 (partial content) instead of 200.

With that in mind, you can now ‘range’ download hundreds of huge files in parallel.

Powered by WordPress