Loadster is a distributed load testing platform for web applications, web services, and static websites. As a cloud-hybrid solution, it can generate load from dozens of cloud regions or from your own self-hosted engines. You can test sites running on the public cloud, or behind the firewall on your own private network.
Soon, you’ll be creating test scripts to simulate realistic user behavior, and running them in parallel with hundreds or thousands of bots, 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(S). Depending on whether you’re testing a static site, a dynamic web app, or an API, your scripts will be different, but the overall load testing approach is similar.
- Bot (or Virtual User or V-User) - A simulated user. Imagine a human with a web browser. Now imagine thousands of them, all hitting your site at once. Each bot maintains its own session state, cookie store, etc, just like a real user. A load test is comprised of many bots hitting your site at once.
- Bot Group - A group of bots (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.
- Scenario - A recipe for a load test, made up of one or more bot groups. Each group within the scenario can run a different script and have its own settings and behavior, such as simulated network bandwidth, randomized wait times, etc.
- Dataset - Datasets contain unique values for each bot to use. When multiple bots are submitting web forms or other transactional data, you can pull this data from a dataset so each submission is unique.
- Test - A multi-user load test. While the load test is running, you can view aggregated results and analyze errors in real time. After the test finishes, Loadster generates a report so you can share the results with your team.
Load Testing Process
The process for load testing with Loadster generally goes like this:
Create a script to simulate your actual user path through the site you’re testing, as realistic as possible.
Build a test scenario describing how many bots should run your script, from which cloud region or self-hosted engine, and for how long.
Run a test and observe in real time how your site is responding and what errors Loadster is encountering.
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 Load Test 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, which is often a good idea.
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. After all, the results of a load test are only as valid as the assumptions going into it.
Loadster can run Protocol Scripts and Browser Scripts.
Protocol Scripts are a sequence of HTTP/HTTPS requests for low-level testing. Since they let you fire off each request individually, protocol scripts are ideal for testing APIs and simple static websites.
Browser Scripts control real headless web browsers, similar to Selenium or Puppeteer or Playwright. With steps like “navigate to page” and “click on element”, browser scripts are best for complex web applications.
Load testing with browser scripts costs more than with protocol scripts, because real browsers are a lot more resource-intensive.
With Loadster, you are free to choose protocol scripts or browser scripts (or both!) depending on your budget and what kind of site you are testing.
Handling Dynamic Data
Many sites have a way for users to submit their data through web forms or uploads. This is especially true of web apps and APIs.
For example, a login page expects each user to submit their own username and password. To load test such a login page, you can parameterize your script with unique data for each bot from a Dynamic Dataset.
Running Load Tests
To run a load test with many bots at once, you’ll need to create a test scenario. Scenarios define one or more bot groups, each of which has some number of bots executing a script. Scenarios can be configured with many different options, such as the number of bots, instructions for ramping the user load up and 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, modify the scenario, and restart the test if you need to.
Once Loadster has finished the load test and collected and processed your test data, you’re ready to analyze and interpret the results so you can evaluate whether the test passed or failed, and plan your next steps.