1. Separate total time into useful parts
If the only metric is total response time, every solution is a guess. A practical investigation separates controller time, service logic, database queries, external calls, serialization and network effects.
This separation helps the team avoid expensive changes that do not touch the real bottleneck.
- Measure p95 or p99 latency for affected endpoints.
- Log database query duration for slow requests.
- Measure external API calls independently.
- Check payload size and serialization cost.
- Compare behavior before and after deployments.
2. Database behavior is often the first suspect
Many Spring Boot performance issues come from missing indexes, N+1 queries, large result sets, uncontrolled joins or filters that cannot use an index. The application can look slow while the root cause is query shape.
Before adding cache, confirm whether the database is doing predictable work.
- Review query count per request.
- Look for N+1 patterns in list endpoints.
- Use pagination for large collections.
- Check indexes used by critical filters.
- Avoid returning fields that the client does not need.
3. Infrastructure changes come after evidence
CPU, memory, container limits, connection pools and network can absolutely affect latency. But changing them first can hide application problems and make costs grow without control.
A careful performance fix includes measurement, one change at a time and a rollback option.
- Check container CPU and memory during slow periods.
- Review connection pool saturation.
- Validate timeout configuration for integrations.
- Apply one change and compare the same metric again.
- Document the evidence that justified the change.
How to use this article
Treat this page as a decision aid. Use it with the related hub, checklist or service route when the topic affects production, customer experience, deployment, security or business continuity.