Previously Loadero had the same amount of compute power assigned to each participant in every test, but applications that our customers test are different and have different demands for end user machine resources. That is why we added compute units to give our customers better flexibility in test creation. This also allows to run much larger load tests as well as optimize cost of running the tests for the applications that don’t use much compute power.
Compute units is a value that determines how many machine resources will be assigned to specific participants, allowing to create a bigger resource buffer for more demanding tests. In the same time also saving money, by assigning lower compute unit value per participant, when testing an application with low client-side machine resource usage. Keep in mind, that these compute unit values are set to specific participants allowing to mix and match different compute unit values in a single test.
What are the changes
Previously all test participants in Loadero had average computing power, which was enough for most of our customers. But there are cases when extra computing power is necessary, for example in testing WebRTC applications for video conferencing, the demand for which has been growing lately. But on the other hand, there are ecommerce apps that require less computing power to perform the test, for example when load testing their web apps to prepare for upcoming events like Black Friday. So we wanted to give our users more control over setting the participant parameters for a test according to their needs.
In Loadero we allow configuring each participant in the test tailored to your needs, and now it’s also possible to set how much machine resources will be used for that participant. We measure these machine resources using compute units. Each full unit contains 0.5 CPU cores and 1 GB of system memory. Until now Loadero participants always had 1 CPU core and 2 GB of system memory, which now is the G2 compute unit.
There are 5 predefined values that can be used, check out the table below!
| Compute unit | CPU cores | System memory |
G0.5 | 0.25 | 0.5 GB |
G1 | 0.5 | 1 GB |
G2 | 1 | 2 GB |
G4 | 2 | 4 GB |
G6 | 3 | 6 GB |
The new subscription limits
Introducing compute units also required changes on how we calculate the limits for subscription plans. Previously the limits were strictly set on participant amounts. Using compute units instead allowed us to do pricing refinements that resulted in lower costs for the majority of our customers. Check out our pricing plans and determine which one is the most suitable for your use!
| Subscription plan | Max compute units in a test | Compute units included in plan (per month) | Max allowed compute unit size |
| Trial | 100 | 100 | G1 |
| Pay as you go: Essential | 20 000 | – | G2 |
| Pay as you go: Ultimate | 50 000 | – | G6 |
| Monthly | 10 000 | 10 000 | G6 |
| Yearly | 10 000 | 10 000 | G6 |
How to pick the right one
Picking the right value for compute units fully depends on the app you are testing. For example, when using video or audio feed, we would suggest taking at least G2 compute unit participants that will provide 1 CPU core and 2 GB of system memory. For more resource demanding actions like group calls or peer-to-peer calls most of the time G4 or higher compute unit is necessary.
If the test consists only of navigation in the app and the app itself does not generate additional load, then a G1 or G2 compute unit most likely is enough. Keep in mind that web apps that have a lot of animations tend to generate more load and in some cases even more than G2 can provide.
In case of simple tests like navigating the page, we would suggest at first giving some resource overhead and only then determine the most fitting compute unit amount based on the machine statistics that are collected in performance tests, keep it simple – if used resources only consist of less than half of the max allowed, you might want to consider checking out how the test behaves at a lower tier compute unit. Check out our blog post about run results for a better insight. If this is not an option or it’s a load test, the best bet would be trying out the test in performance mode with less participants. If your tests were running fine before, picking the G2 compute unit most likely could be the middle ground of price and performance.
Summary
We are very excited for the new changes, especially because this feature has been in the works for a long time. If you already have tests in your Loadero project, make sure to check your compute units setting. If your application is not very compute power demanding, you may choose to assign less compute units per participant and save some money on your future test runs. But if you are just getting ready to run your first tests and are not sure which compute unit size is right for you, you can use the web chat in Loadero interface to contact our support team for help.
