Java performance engineering

We diagnose difficult production problems across Java, the JVM, JDBC, transactions, and databases. The work starts with evidence and ends with a root cause your team can verify.

Start Java performance triage Browse experiments Discuss a problem

Problems we diagnose

Slow or unpredictable requests
High CPU and infrastructure cost
Memory growth, leaks, and excessive GC
JDBC, transaction, and database bottlenecks
Concurrency and shared-resource contention
Performance problems that resist reproduction

Follow the evidence across layers

A symptom in one layer often begins somewhere else. A depleted JDBC pool may start with transaction scope or a database lock. GC pressure may start with application allocation or retention. High CPU may reflect contention, retries, or queue buildup rather than productive work.

We correlate evidence instead of tuning each component in isolation.

Application code and framework behavior
JVM execution, allocation, memory, and GC
Threads, locks, queues, and concurrency
JDBC connections and transactions
PostgreSQL query execution and locking
MariaDB query execution and locking

Java experiments

Short, reproducible tests of JVM startup, memory, packaging, and deployment. When a result needs more room, it becomes a full article. We use small experiments to test JVM and framework hypotheses before turning them into production recommendations.

Spring Boot fat JAR vs extracted layout

September 11, 2026

The official extracted layout cut median startup 23.3% and first-request latency 34.1% in six paired runs.

Spring Boot vs Quarkus on a 512 MB VPS

September 2, 2026

The same workload, JDK 25, and 80 MiB heap. Quarkus started larger, then had the smaller resident set.

Spring Boot on a 256 MiB VPS with JDK 25

August 25, 2026

Compact object headers helped, but swap and scheduling delay kept the result in stretch-test territory.

Production engineering notes

A few production performance problems we worked on at Google, Apple, and ServiceNow. Details have been anonymized and simplified.

Connection pool starvation

Troubleshooting production slowdowns caused by exhausted connection pools and requests waiting for database connections.

MariaDB history list growth

Tracing history list length growth to an open transaction that prevented old row versions from being cleared.

Production deadlocks

Troubleshooting deadlocks in production by connecting thread and transaction behavior to the resources involved.

Excessive garbage collection

Identifying performance bottlenecks caused by excessive GC, including memory leaks, wasteful logging, and unnecessary in-memory processing.

If the investigation is stuck

Tell us what changed, what you have measured, and where the trail went cold.

Discuss a performance problem