☑ Throughput on single EC2 instance: 100 RPS
☑ Latency Goal: < 2,000 ms under load
☑ Error Rate Goal: < 1% under load
| Requirements | Goal |
|---|---|
| Throughput on single EC2 instance |
100 RPS |
| Latency | < 2,000 ms under load |
| Error Rate | < 1% under load |
K6 stress test queries are promising; already below 2000ms latency cap:
- Add indexes and set access method to "hash".
- Refactored looping query for building an array of photos into a single query. Reduced stress on the database which was affecting response times.
- Refactored insert into values (row constructor) for adding photos to the database, to insert into select (table constructor). Insert Into Values required about 15-20 lines of code, and Insert Into Select only required 3.
Initial test of 100 RPS looked promising with average response after initial spike between 2 - 3 ms and 0.0% error rate. Database is both consistent and fast. Next stress load will increase to 1,000 RPS:
Stress test of 1,000 RPS also looks fantastic with an average response after the initial spike between 2 - 5 ms and continues to hold a 0.0% error rate.
Database continues to be consistent and fast despite the significantly higher sress load and surpasses the goals for the System Requirements.
Final test of 3,000 RPS to determine when scaling would be necessary. With this amount of stress load, response times are still below the 2,000 ms latency threshold, with the average response time of 1,625 ms and continues to be consistent with an incredible 0.0% error rate. Despite the slower response times, users will still get the data they're looking for.
1,625 ms response times do not give a great user experience. Recommend scaling horizontally to increase throughput capabilities.