When using load testing tools for mobile apps, the tests should be as realistic as possible. On the other hand, it is also important not to become too perfectionist and waste time on unimportant details. It is even better to do a few iterations, without improvement of the system to be tested, and only to make improvements on the testing process. To do this, it is necessary to establish the loads for which the app behaves linearly.
A large number of web application hosts are paid according to the consumption of bandwidth, CPU or RAM applications on the infrastructure. Therefore, remember that load testing may cause your consumption to skyrocket. However, according to a study, a majority of web users who have been confronted with a performance problem on an online sales app claim that they will not place a new order with this app, and nearly half of them say they are likely to advise against the app to their friends.
Also, some results may bias the statistical calculation since, in the majority of cases, the distribution of the response times does not follow a normal distribution, which means that a very long distribution tail biases the calculations. On the other hand, if no gain is perceived as a result of optimization, or the benefit is less than a few percent, it is because an optimization is not providing the increases it should. Remember, there are different types of load tests as well as theories that should be applied when recovering metrics. Also, view this link for more data: https://en.wikipedia.org/wiki/Load_testing
Also, there are cases where an application uses an outside service (mapping data server, validation server of a credit card number, etc.) A merchant app can generate tens of thousands of connections per minute. And remember, an online commerce app will have different requirements for managing the ordering procedures of thousands of users. Load test scenarios should therefore also include all validation points, transactions, and measurements.
Of course, the cost of implementing optimization must also be taken into account. If load tests are performed manually these scenarios can quickly become tedious (empty the caches, initialize the database, purge the message queues, etc.) Manual load tests are also prone to errors and omissions, thus distorting the results. Also, view this link for more data: https://en.wikipedia.org/wiki/Stress_testing
In addition to the limits of the target tested, attention must be paid to the hardware part of the load tests for the same reasons. The volume of data collected complicates the analysis of the results. Also, the test environment must be entirely dedicated to ensuring test stability.
In recent years, as part of the agile development process, several companies have performed their load tests much earlier. It all depends on the complexity of the tested system. If you have only one application server, and a database, the metrics can be exploited by going to each metrics collection tool. On the other hand, if the system architecture becomes more complicated with proxies, a cluster of application servers, a message broker, etc., then you will need to automate your metrics collections.