What this prompt does
This prompt makes the model run a JPA/Hibernate performance audit and return concrete, prioritized fixes instead of generic advice. Its main target is the N+1 query problem — the one Hibernate hides best, because the extra queries fire lazily where you can't easily see them — but it also covers fetch strategy, batching, caching fit, and DTO projections. Every finding comes with before/after code and an expected impact, so you can rank the work instead of guessing.
The [stack] variable sets the exact Java/JPA versions so the recommendations match your APIs. [symptom] describes what you're observing (for example a slow list endpoint under load), which steers the audit toward the likely cause. [hot_paths] names the entities and queries under pressure so the analysis focuses on them rather than the whole schema, and [sla] gives the latency target the fixes are measured against so severity is judged against a real bar, not a feeling.
When to use it
- A list or detail endpoint is slow and you suspect hidden N+1 queries.
- Deciding between
@EntityGraph, fetch joins, and batch fetching for a hot path. - Checking whether second-level or query caching actually fits, or is the wrong tool here.
- Replacing heavy full-entity loads with DTO projections on read-heavy endpoints.
- Producing a prioritized, evidence-backed tuning plan rather than scattered tweaks.
- Validating that annotations match the SQL Hibernate actually emits at runtime.
Example output
You get a prioritized findings table — severity, fix, and effort — followed by before/after snippets for each item. The audit hunts N+1 patterns (EAGER traps, lazy access outside transactions, per-row collection iteration), recommends @EntityGraph or fetch joins where they replace N+1 while warning where they cause cartesian blowups, checks batch size and statement caching, evaluates cache fit honestly, and suggests DTO projections with read-only transactions. Each finding states the expected query-count or latency change measured against [sla]. It's a ranked, actionable report, not generic tips.
Pro tips
- Always confirm step 1 against the actual SQL log — the ORM's behavior rarely matches what the annotations imply, so verify the real query count.
- Make
[hot_paths]specific; naming the exact slow entities and their relationships gets you targeted fixes instead of a generic checklist. - State
[sla]as a real percentile target like p95 so the fixes can be judged against a concrete bar. - Describe
[symptom]precisely so the audit steers toward your actual problem rather than auditing everything at once. - Watch for cartesian blowups when applying fetch joins — they replace N+1 but can balloon the result set on multiple collections.
- Treat caching skeptically; the audit flags cases where it's the wrong tool, and masking an N+1 with a cache hides the real problem.
