Loadster Key Concepts
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 & Concepts
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. Think of a human with a web browser. Now imagine thousands of them, all using your site at once. Each bot maintains its own independent session state, cookie store, etc, just like a real user. A load test is when many bots are hitting your site at once. Loadster has two types of bots: Protocol Bots, with multithreaded HTTP clients, and Browser Bots, with real headless web browsers.
- 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.
The High-Level Load Testing Process
The process for load testing with Loadster generally goes like this:
Create a script to simulate a user’s path through the site you’re testing, as realistically as possible.
Design a load test scenario describing how many bots should run your script, from which cloud region or self-hosted engine, and for how long.
Run a load 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 test 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’s bots 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’re free to choose protocol scripts or browser scripts (or both!) depending on your budget and what makes sense for the site you’re testing.
Handling Dynamic Test Data in a Load Test
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.
A load test in which every bot submits the exact data isn’t great for dynamic web apps, because the application or database might cache a lot of things, leading to artificially good results. It’s better to mix up the dynamic data in your tests.
Running & Observing Load Tests
To run a load test with many bots at once, you’ll need to create a load test scenario. Scenarios define one or more bot groups, and each bot group includes some number of bots executing a script. A scenario specifies the number of bots, instructions for ramping the load up and down, how long to run the test, whether to use full bandwidth or simulate a slower connection, and so on.
Once you’ve designed a scenario for the load pattern you want to test, 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 early, modify the scenario or scripts, and restart the test if you need to.
Analyzing & Interpreting Test Results
Once Loadster has finished the load test and collected and processed your test data, it’s time to analyze and interpret the results so you can evaluate whether the test passed or failed, and plan your next steps.