Before the load test, it's necessary to populate the user database of the application to be tested with a large amount of users. In this case, the database was populated with 100,000 users. The load test can be performed with an estimate of the ratio of logging-in users and new registrations. Here, it is assumed that the ratio between returning users logging in and new users signing up is 9:1.

For the test highlighted in this document, the objective is to test up to 100 transactions per second, with the load test originating from two regions; the East coast of the U.S. and the West coast of the U.S..

A best practice is to plan the maximum amount of transactions per second in advance even if there’s no plan to reach it. This is because the CloudTest grid manager needs to "spin up" or run that amount of servers first to cater for the expected max load. Otherwise, it might involve downtime while the CloudTest configuration is being retooled.

Best practice 1

Plan in advance the maximum amount of transactions per second with additional safety buffer included.

Best practice 2

Populate the user database as if these are real users and make sure the passwords are also fully encrypted as in a real-world scenario to ensure the full load. The hashing algorithm should also match that which is used in the production system (for example, bcrypt). Password complexity should also follow any password patterns that the customer has implemented.