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 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 →

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