What this prompt does
This prompt turns the model into a methodical Spring Boot performance engineer. Instead of guessing at JVM flags, it forces a structured audit across ten layers — JVM and garbage collection, the Tomcat/Netty thread pool, the HikariCP connection pool, JPA/Hibernate batching, the Spring Cache abstraction, HTTP compression, async processing, slow-query optimization, profile-based config, and continuous profiling. Crucially, it asks for before/after metrics on every change so you can tell which optimizations actually earned their place.
The variables anchor the work to real numbers. You set [current_rps] and [current_p99] as your baseline and [target_rps] and [target_p99] as the goal, which keeps the model honest about whether a change closes the gap. [spring_version] and [db_type] shape the tuning advice (HikariCP defaults differ by database), [gc_algo] lets you compare collectors like ZGC against G1GC, and [cache_provider] with [cacheable_data] decide what gets cached and where. [async_candidates] and [profiler] round out the throughput and observability story.
When to use it
- A Spring Boot service is missing its latency SLA and you need a systematic plan rather than ad-hoc tweaks.
- You are sizing an app for higher traffic and want to know whether the JVM, the pool, or the queries are the bottleneck.
- A new database (
[db_type]) was introduced and connection-pool defaults need re-tuning. - You want to evaluate a GC change like
[gc_algo]with measured evidence instead of folklore. - Onboarding to an unfamiliar codebase and you need a repeatable tuning checklist.
- Preparing a performance review or capacity-planning document that needs before/after numbers.
Example output
Expect a layered report: one section per optimization area, each describing the current setting, the recommended change, and a before/after metric (throughput, p99, heap, GC pause, or pool wait). Slow queries arrive with EXPLAIN ANALYZE output for the top offenders, and the JVM section lists concrete flags with rationale. It reads like a tuning playbook you can execute and re-measure step by step.
Pro tips
- Fill
[current_rps]and[current_p99]with real measured numbers, not estimates — the whole before/after framing collapses if the baseline is invented. - Keep
[cacheable_data]to data that is genuinely read-heavy and tolerant of staleness; caching volatile data with[cache_provider]causes correctness bugs, not speed. - When comparing
[gc_algo]options, run each under representative load; ZGC and G1GC trade differently depending on heap size and pause sensitivity. - Be selective with
[async_candidates]— only push fire-and-forget work like logging or analytics off the request thread, never anything the response depends on. - Match
[spring_version]to your actual version, since thread-pool and Hibernate defaults shifted between releases and stale advice can mislead. - Treat the profiler step (
[profiler]) as ongoing, not one-off; the bottleneck usually moves after the first round of fixes.
