App load testing with Loadster

Overview (what Loadster does)
Loadster is a load testing tool for web applications or REST APIs which allows you to simulate a large amount of traffic interacting with your application.
We use Loadster rather than their competitors for 2 reasons:
1.Great UX. A Chrome extension allows you to record the actions of the test as a user, rather than having to write abstract code that simulates the actions a user would take.
2.Ability to easily use dynamic datasets as a source for bots, allowing use of Loadster to load up the database with data, or to test as many users at the same time.
When to load test
For projects that will have a lot of users or a lot of data, load testing is necessary. Some examples of this are:
Lots of users
There is an existing user base on another application who will immediately transition to the finished app when it is released.
The company developing the app expects a high-profile release (e.g. trying to get top of Product Hunt, lots of money for targeted marketing, or relationships with the press that will get the product featured on high-profile platforms).
Lots of data
Searches are "expensive" or take a lot of computing power to calculate.
For example, users are searching "any field" across a database of 10,000+ items, each of which has several long texts.
Nested searches on pages cause lots of data to be downloaded when users access popular pages.
 The app constantly processes webhook events from all users, for example, listening to updates on stock prices that they are following and alerting them when some condition is true.
"Spiky" app usage by design
Every day at midnight, the app must process a lot of transactions
App usage occurs primarily between certain limited hours, like an app where 30 students in each classroom are all going to use it at the same time, and hundreds of classrooms could potentially use the app.
New "drops" of content (e.g. a fashion line releasing a new pair of shoes) result in huge spikes in traffic
Complicated/CPU intensive workflows
When the app relies on some complex logic that is often triggered, app CPU usage can get used up more quickly than you'd like. Usually this goes hand in hand with the "lots of data" item. In some apps, lots of custom logic is applied to each piece of data they processed, using multiple custom plugins that take up a lot of CPU power.
Metrics to pay attention to
Number of errors
Errors can be because of a misconfigured Loadster test, or a deeper problem, like:
Not enough app capacity
Bugs with the app design that cause it to fail when too many objects are present.
For example, a custom Bubble plugin could work well with 50 objects, but consistently fail when 500 objects are used as inputs.
Average page load time with low load (few bots)
Average page load time with high load (lots of bots)
Compare this to the average load times with few bots running on the page. This will help see if/when the app is beginning to strain and hit the limits of its capacity usage.
Capacity usage on Bubble app over the time the test is run
Test CSV / generating test data
Random data
In many situations, generating random data within Loadster can be sufficient for load testing, especially if the data will be deleted soon after.
To type in an email, for example, the expression chris+${randomalphanumeric(8)}@airdev.co 
works. This generates an email with 8 random number and letter characters in it.
To generate a random 5 digit number, randomnumeric(5) works. 8 and 5 in the above examples can be substituted with other numbers (e.g. 3, if the generated number must be between 0 and 1000).
Script Variables & Expressions
loadsterperf
More info about how to generate random expressions and other programmatic operations
Uploaded data
Loadster can also access data from CSVs instead of random data.
Mockaroo can be used for generating human-readable test data if necessary. Below is a sample file generated by mockaroo (without headers) with first and last names. The emails generated used real domains and could have resulted in our SendGrid account getting blocked for spam, so instead a column of emails was added via a script. (Instead of adding a column of emails like this, make use of Loadster's random data feature.)
Uploaded dataset
combined_data.csv
47KB
Binary
Cost
Tests are billed based on the number of bots that are run, and the amount of time that those bots run for.
1 "Browser bot", which is the type of bot used in the flow described here, uses 4 units of "fuel" per hour. In February 2022 this translates to $119 buying enough credit for 1000 bots to run for 15 minutes. For most load tests, that would translate into the bots loading the page once every 15-30 seconds, so 30,000-60,000 loads over 15 minutes (or stretched out over a longer period). Note that bots are billed based on the exact amount of time used, which helps keep billing simpler.
Video example setup
Dynamic Datasets and Script Variables
loadsterperf
note that this explains how to set up variables in a way i didnt know how to do  
Use ${user[1]} (where "user" is the name of the variable) to get 2nd column of a dataset, rather than uploading multiple separate datasets. 
Here's another test using dynamic datasets to load the app up with data over a long period of time, and which also explores the random variables mentioned in the "generating test data" section above.
Last modified 1yr ago