The OpenJDK team says don't pool virtual threads. We measured what pooling buys - 8% less allocation - and what it costs - 60 MB of near-empty stack chunks - and found that it saves the cheap thing and keeps the expensive one.

We found our benchmark was measuring Spring's warmup, not its peak. We changed it. Spring's numbers went up. Quarkus's didn't. That's what fairness looks like.

A companion to the Foojay podcast episode, this post distills the key questions and answers about Quarkus — from build-time optimization and live reload to JVM versus native trade-offs and cloud cost savings.

Francesco Nigro shares hard-earned lessons from years of performance engineering work: why performance is a currency, how to benchmark responsibly, the dangers of LLM-assisted analysis, and the mindset required to make real discoveries.

Mark Stoodley explains how IBM Semeru Runtimes and the Eclipse OpenJ9 JVM deliver faster startup times and lower memory footprint through shared classes cache technology, and how Quarkus makes it easy to take advantage of these benefits.

Throughput averages hide warmup problems. On 4 cores with 100 connections, C2 compiler threads are starved by platform threads. pidstat and JFR show how.

Our perf-lab shows Quarkus 2x faster than Spring, but a community member only sees 1.19x locally. The culprit: a userspace TCP proxy hidden inside rootless podman.

Quarkus 3.35 introduces Profile-Guided Optimization (PGO) support for native images. Enable it with quarkus.native.pgo.enabled=true and let your integration tests drive the profiling - the build automatically produces an optimized native binary tailored to your application's actual runtime behavior.

Quarkus 3.35 brings great startup improvements to IBM Semeru Runtimes. The same `quarkus.package.jar.aot.enabled=true` flag that activates Project Leyden on HotSpot-based JVMs now automatically generates an OpenJ9 Shared Classes Cache - no code changes needed.

In 3.35, we are going to enable reflection-free Jackson serializers by default.

You might have read our first post about Project Leyden and the new perspective it brought, but how did we actually integrate it into Quarkus? In this post, we share our journey and the improvements we made along the way.

We wrote a new benchmark.

This is a story about Project Leyden. And this is not a story about Project Leyden. It is a story about how Project Leyden gave us a new perspective on how we think about startup performance in Quarkus.

When Quarkus was first released, the industry was focused on microservices. But Quarkus is just as well suited for large monoliths, whether you're modernizing existing systems or building new ones from scratch. In large applications, build times quickly become a bottleneck, and we've made significant improvements here. Let's discuss these!

This post explores how Quarkus speeds up development, cuts costs, and streamlines cloud-native Java.

This blog post invites you to discover how Quarkus can help your company cut costs, streamline development, and modernize your Java stack for today’s cloud-native world.

Leveraging Quarkus build-time metaprogramming capabilities to improve Jackson's serialization performance

By carefully fixing and designing a performance test to ensure that only Quarkus is being stressed, throughput improves from 1.75 req/sec to nearly 26,000 req/sec

Understand when and how to use the Quarkus IO thread and its influence on microbenchmarks.

Quarkus has so far been focused on start-up time and memory footprint, but runtime performance is important as well. Find out how well Quarkus performs in both Native and JVM modes.