Card 05/ 06
Practice: Diagnosing a Slow Endpoint Report
A vague support ticket, one telling detail, and the first thing to do before changing any code.
Diagnosing a slow endpoint starts with measuring it, not with changing the code that looks guilty. Read the report below, decide what you would do first, and say which cause its one detail points towards, before you open the answer.
A support ticket says: "The rides list page is slow, especially when there are a lot of results." There is no other detail, and nobody has changed the endpoint's code recently.
See the answer
Measure it: turn on SQL logging or check the endpoint's existing metrics, and see what a request does. "Especially with a lot of results" points strongly towards the N+1 query problem, one query for the list and then one more for every row in it, because its cost grows with the number of rows.
A hint is still not a diagnosis. Confirm it by counting the queries for a small list and a large one: if the count grows with the rows, it is N+1, and a fetch join is the fix.
- Spring Boot
- Performance
← → move through sections and cards