Measuring Performance Before Optimising

Measuring first means finding out where the time goes, with timings and logs, before changing any code to make it faster. "The API feels slow" describes a symptom, and several unrelated causes produce the same symptom: an N+1 pattern (one query for a list, then one more per item), a missing cache, a slow remote call, or something else entirely.

The loop that finds the real cause is measure, identify, optimise, repeat. Look at real request timings, the database query log and whatever monitoring is already in place before touching any code.

In Spring Boot, spring.jpa.show-sql=true prints every SQL statement Hibernate runs, which is enough to count queries per request, and spring.jpa.properties.hibernate.generate_statistics=true makes Hibernate report query counts and times. Spring Boot Actuator's metrics show how long each endpoint takes in production.

On the rides list, for instance, turning SQL logging on and loading the page with 10 rides and then with 100 would show 11 statements and then 101. That settles the cause in a minute: the count grows with the rows, so it is N+1.

A method rewritten because it looked like the suspect is a coin flip. A method rewritten because the query log showed it running twenty-one queries per request is a fix, and the log confirms it afterwards.

This is also why missing monitoring is a performance problem in its own right: without request timings and query counts already in place, measuring first has nothing to measure with, and every investigation starts from a guess.