Getting Started

Loadster is a platform for distributed load testing of your web applications, web services, and static websites from the public cloud or private networks.

Soon, you’ll be creating test scripts to simulate realistic user behavior, and running them with hundreds or thousands of concurrent users, to measure and improve your site’s scalability and performance.

Load Testing Terms

First, let’s take a second to get familiar with a few of the terms you will see within this manual.

  • Site - Here in the Loadster docs, we frequently use the term “site” broadly to describe a website, a web application, or an API. Pretty much anything HTTP. So if you’re testing an API or dynamic web application, your scripts will be different, but the overall load testing approach is similar.
  • Virtual User or V-User - A simulated user. Imagine a pretend user sitting in a chair somewhere with a coffee and a web browser. Now imagine thousands of them! Each virtual user has its own session state, cookie store, etc, just like a real user’s browser. A load test typically consists of many virtual users (v-users) hitting your site at once.
  • V-User Group - A group of virtual users, all running the same script with the same configuration. You can have multiple groups in a load test if you need to simulate multiple user behaviors or configurations simultaneously.
  • Script - A sequence of repeatable steps. Some steps make a single HTTP(S) request for a web page or API endpoint (optionally with static content resources, capturing rules, and more). Other steps represent wait times between requests. More advanced steps execute arbitrary Code Blocks so you can implement conditionals, looping, and custom parsing with JavaScript.
  • Scenario - A recipe for a load test, made up of one or more virtual user groups. Each group within the scenario can have its own settings and behavior, such as simulated network bandwidth, randomized wait times, etc.
  • Dataset - Datasets contain unique values for each virtual user to use. When multiple virtual users are submitting web forms or other transactional data, you can pull the data from a dataset so each submission is unique.
  • Test - A multi-user load test. While the load test is running, you can filter data and analyze errors in real time. After the test finishes, you can export a report and share the results with your team.

Load Testing Process

The process for load testing with Loadster generally goes like this:

  1. Create a script to simulate your actual user path through the site you’re testing, as realistic as possible.

  2. Build a test scenario describing how many virtual users (v-users) should run your script, from which cloud region or self-hosted engine, and for how long.

  3. Run a test and observe in real time how your site is responding and what errors Loadster is encountering.

  4. Analyze the results of your test and figure out what went wrong.

It may take multiple load tests (sometimes quite a few) to get a full and accurate picture of how your site performs and scales. It’s usually a good idea to create a baseline load test scenario and re-run it periodically as your site and hosting environment changes, to make sure performance doesn’t degrade and bottlenecks aren’t introduced.

Creating Your Scripts

A script simulates the path of a single user through your site. You can create multiple scripts if you want to simulate multiple user paths in the same load test (recommended for most sites).

Your scripts should replicate real user behavior as closely as possible. The more realistic your set of test scripts, the more useful your load testing results are going to be. The results of a load test are only as valid as the assumptions going into it.

With Loadster, you can record your scripts in an ordinary web browser, or you can add and edit steps manually.

Handling Dynamic Data

Many sites have some way for users to submit form data or uploads. This is especially true of web applications and APIs. For example, each of your users may have a different username and password, email address, and other data that they will enter into forms or submit to an endpoint. In this case, you can supply unique data for each v-user with Dynamic Datasets.

There will also be times when the application returns dynamic data for each user. An example of this would be account creation: if your script registers a new account, the web application may assign a unique id that will need to be reused later in the script. Have a look at Capturing Rules and Validation Rules to learn more about dealing with dynamic responses from your site.

Running Load Tests

To run multiple users at once, you’ll need to create a test scenario. Scenarios include one or more v-user groups, each of which contains some number of v-users executing the same script. Scenarios can be configured with many different options, such as the total number of virtual users, instructions for ramping the user load up/down, simulating network bandwidth, etc.

Launch the scenario to run a load test. Make sure to keep an eye on the test as it runs, to see how your application is responding to the load. You can always stop a test prematurely, tweak it, and restart the test if you need to.

Analyzing Results

Once Loadster has finished the load test and collected and processed your test data, you’ll need to analyze and interpret the results so you can evaluate whether the test passed or failed, and plan your next steps.