Loadster 2.1 is released!

Let’s take a break from our normal programming to announce the release of Loadster 2.1! This is a minor-version release that’s free to all existing users, with a few important features.

Variable Capture from HTTP Headers

Loadster lets you capture values from an HTTP response (typically a dynamic page). Now, it supports capturing from HTTP response headers too, not just the body!

Why is this important? Well, lots of web applications use a “save-and-redirect” pattern. When you submit a web form (let’s say) to create a new entity in the database, that new object will likely have an ID. After receiving the POST, many web apps will then send an HTTP 302 redirect so the user can view the newly created entity. That way if the user refreshes the page, it won’t resubmit the post and create a duplicate entry.

When creating automated load test scripts in Loadster, it’s really essential that you be able to capture this ID and use it later on in the script. Sometimes it’s also important to capture other dynamic values, such as cookies or session IDs.

Setting up a capturing rule in the script editor is simple:

Variable Capturing 1

After that, you can use the variable you captured in subsequent requests, like so:

Variable Capturing 2

Every time that variable is encountered, Loadster will dynamically substitute the value that was most recently captured. Remember, variables are unique per virtual user, so each virtual user can have their own dynamic session data just like real users would.

Virtual User Population Details

Another little bonus in Loadster 2.1 is the addition of more details on virtual user populations in a test report. Loadster previously let you configure these variables for each population, but they were missing from the final report and trying to recall them afterwards was no fun.

Virtual User Population Details

As you can see, Loadster virtual users have a lot in common with real web browsers. They have configurable timeouts, and can make use of multiple parallel download threads for loading page resources (images/CSS/JavaScript). The number of threads per v-user is configurable and defaults to 6.

What’s next?

We have a really aggressive roadmap over the next couple months that is going to be really exciting, including some much bigger stuff than what I just talked about. I can’t tell you exactly what just yet because, well, you know…