Load testing for the backend API. This test currently hits the development environment and has several limitations. Here is the information about the test:
- Hatches: how users are spawned into the target host. For example, if you target 100 concurrent users to request an API endpoint, the users will be spawned over 10 seconds after the test is initialized.
- Concurrent users: how many users to simulate in our system, and whether their behaviour leads to failures or normal operation. The average RPS (requests per second) for that host is only 9 RPS, with a maximum of up to 15 RPS. This means the server could handle an average of 9 RPS with 100 concurrent users, with an average response time of 9,937ms (almost 10 seconds) and a 95th percentile response time of 13,000ms (13 seconds).
- In addition, these concurrent users are not unique users. It’s the same user replicated 100 times. Note that they are not differentiated by different request payloads, etc.
- After testing several scenarios, the RPS did not increase (it should increase because the time between request and response also increased). Based on the documentation, the problem might come from the target host or server (such as CPU, memory & network, database, DNS performance, etc)1
- These load testing results also provide some answers about why the response time on the development side is relatively slow compared to production. Of course this is expected because the development environment is not optimized for performance and scalability