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.

Browse experiments Start Java performance triage 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

Featured experiments

Measurements of Java memory, frameworks, connection pools, and persistence. Each write-up explains the workload, results, and limitations, with links to the experiment record.

Frameworks and runtime

Spring Boot, Quarkus, and Micronaut: JDBC on a 1 GiB VM

Equivalent JDBC apps on Java 25, measured one at a time for startup, resident memory, and CPU. Quarkus had the lowest overall median RSS; its memory use converged with Micronaut’s near the end of this single run.

Database and persistence

Jdbi, MyBatis and jOOQ with Javalin on a 512 MiB VM

Two runs per library with H2, 512 MiB RAM, and no swap. MyBatis used the least median workload RSS; Jdbi was competitive on latency. Includes repository code and a separate monitored MyBatis repeat.

Spring Boot JPA vs JDBC

A small stars app used about 90 MiB less RSS with JDBC than with JPA and Hibernate, and reached its dashboard about four seconds sooner.

All Java experiments →

Discuss on daily.dev ↗

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