Virtual-Threads on tsvinc

The Throughput Was Always 115

Thu, 02 Jul 2026 00:00:00 +0000

Part 17 of the Micronaut native image series. Follows Part 16, which compared reactive vs imperative on a lighter workload. Assumes familiarity with Project Reactor and virtual threads.

115

That’s the number. Requests per second. For all twelve scenarios.

Reactive R2DBC on native: 115. Imperative JDBC on JVM: 115. Virtual threads with loom-carrier: 114.5. Reactive on JVM with 512 MB memory limit: 115.2. Imperative on JVM unlimited: 115.1.

Twelve benchmark runs. Two codebases. Three runtime configurations. Six memory/container permutations each. 0% failure rate across the board. And the same number, over and over, like a metronome that doesn’t care what’s playing.

Designed a Reactive Benchmark. Imperative Won.

Tue, 30 Jun 2026 00:00:00 +0000

Part 16 of the Micronaut native image series. Follows Part 15, which benchmarked the reactive service alone. Assumes familiarity with Project Reactor and virtual threads.

The Hypothesis

The workload was designed to make reactive shine. Six endpoints exercising parallel fan-out, scatter-gather, bounded concurrency, and backpressure. A Go mock server injecting realistic latency jitter — ISS at 10-50ms with 3% failures, NEO at 30-150ms, connection resets via Hijack() + conn.Close(). k6 ramping to 200 VUs then sustaining 500 req/s constant arrival. If reactive Micronaut had a home-court advantage anywhere, it was here.

265 req/s on All Three Runtimes (Until You Add a Memory Limit)

Sat, 27 Jun 2026 00:00:00 +0000

Part 15 of the Micronaut native image series. Assumes familiarity with reactive Java (Mono/Flux) and container memory limits.

The Draw

Native image, JVM, and virtual threads walk into a benchmark. Same reactive Micronaut service. Same k6 load profile. Same PostgreSQL. Same mock APIs with realistic latency jitter.

Runtime	Req/s	Errors	RSS (avg)
Native (unlimited)	264	1.0%	273 MB
JVM (unlimited)	266	1.0%	551 MB
Virtual threads (unlimited)	265	1.0%	543 MB

265 req/s. All three. The error rates match the mock server’s configured failure rate — the application itself isn’t failing. Reactive code runs identically on native image, HotSpot, and loom-carrier Netty.

ExecutorType.VIRTUAL Doesn't Exist

Thu, 25 Jun 2026 00:00:00 +0000

Part 14 in the Memory Benchmark series.

The Config Everyone Writes

micronaut:
  executors:
    io:
      type: VIRTUAL

Every tutorial. Every “Micronaut + virtual threads” blog post. Every AI suggestion. This is the obvious config. One property, clean intent.

It crashes at startup:

No enum constant io.micronaut.scheduling.executor.ExecutorType.VIRTUAL

The Enum That Actually Exists

ExecutorType in Micronaut 5.0.0 has five values:

SCHEDULED
CACHED
FIXED
WORK_STEALING
THREAD_PER_TASK

No VIRTUAL. Never was one.

The Config That Works

micronaut:
  executors:
    io:
      type: THREAD_PER_TASK
      virtual: true

Two properties. type selects the executor creation strategy – THREAD_PER_TASK maps to Executors.newThreadPerTaskExecutor(factory). virtual sets that factory to produce virtual threads instead of platform threads.

We Removed Reactor. Nothing Got Slower.

Sat, 20 Jun 2026 00:00:00 +0000

We took the entire reactive stack out. R2DBC, Mono, Flux, Reactor Core, loom-carrier, flatMap with its carefully-tuned concurrency arguments. Replaced it with JDBC, HikariCP, and blocking method calls. Same endpoints. Same Netty HTTP server. Same PostgreSQL. Same k6 load profile: 10 to 200 VUs, 500 req/s constant arrival rate, seven scenarios each.

Throughput didn’t move. Latency dropped. Memory dropped. GC pauses dropped 63% at 256 MB.

The Scoreboard

This is part of the series benchmarking a Micronaut 5.0.0 app under memory constraints. The reactive version is the one from Part 10 and Part 11 — fully tuned, flatMap concurrency bounded, R2DBC pool sized to match, loom-carrier enabled for virtual threads. The imperative version: JDBC/HikariCP, THREAD_PER_TASK executor for virtual threads, same pool size.

Loom Carrier on a Reactive Stack: 78 MB for Free

Wed, 17 Jun 2026 00:00:00 +0000

“Virtual threads don’t help reactive apps.” You’ve heard this. Probably said it. The reasoning is sound: a fully reactive stack — Mono/Flux from HTTP client through R2DBC to Netty — never blocks a platform thread. Virtual threads solve blocking. No blocking, no benefit. QED.

We ran the benchmark anyway. The conventional wisdom is correct about throughput and wrong about everything else.

The Stack

Space Observatory: Micronaut 5.0.0, Netty, R2DBC PostgreSQL, Reactor Core, Micrometer. Reactive end-to-end — no subscribeOn(Schedulers.boundedElastic()), no blocking JDBC, no thread-per-request anywhere. GraalVM CE 25, Java 25.