Benchmarks on tsvinc

2492, 2495, 2508

Tue, 07 Jul 2026 00:00:00 +0000

Part 19 of the Micronaut native image series. Follows Part 18, which chased a connection pool cancellation leak. Assumes familiarity with JDBC, R2DBC, and JPA/Hibernate.

The Table That Ended the Argument

Workload	Framework	rps	p95
`jdbc-synth`	Quarkus	2508.4	1.2 ms
`jdbc-synth`	Micronaut	2495.0	1.8 ms
`jdbc-synth`	Spring Boot	2491.8	1.6 ms
`r2dbc-synth`	Quarkus	2501.2	1.4 ms
`r2dbc-synth`	Micronaut	2480.2	2.2 ms
`r2dbc-synth`	Spring Boot	2478.7	2.3 ms

Native images at 256 MB. Same k6 load. Same Postgres. Zero errors across the board.

Eight Connections, Zero Available

Tue, 07 Jul 2026 00:00:00 +0000

Part 18 of the Micronaut native image series. Follows Part 17, which found that reactive and imperative produced identical throughput on the 28-API workload. Assumes familiarity with R2DBC and Project Reactor.

60.8 and 59.9

Two frameworks. Different HTTP servers, different dependency trees, different teams maintaining them. Under load, both reactive stacks land at almost the same throughput:

Framework	Model	Runtime	Mem	rps	p95	k6 errors
Micronaut	Reactive	Native	128 MB	60.8	15000.6 ms	14.1%
Spring Boot	Reactive	Native	128 MB	59.9	13548.7 ms	2.0%
Micronaut	Imperative	Native	256 MB	251.9	2554.8 ms	0%
Spring Boot	Imperative	Native	256 MB	220.6	2588.9 ms	0%
Quarkus	Reactive	Native	256 MB	258.7	—	0%

Imperative hits 220–252. Quarkus reactive hits 259. Micronaut and Spring Boot reactive: 60.

Native Image Grew to 734 MB

Tue, 07 Jul 2026 00:00:00 +0000

Part 20 of the Micronaut native image series. Field notes from running benchmark scenarios across 18 branches — three frameworks, three runtimes, four memory tiers. No narrative arc. Just five things that surprised me.

1. Native is not automatically small

The pitch: GraalVM native images are lean. Sub-100 MB footprint. Container-friendly. Cloud-native.

The CRUD workload confirms this. Native RSS across all frameworks ranges from 31 to 86 MB. JVM containers running the same code: 351-643 MB. The marketing copy is accurate — for CRUD.

16,700 Classes Before Your First Request

Mon, 06 Jul 2026 00:00:00 +0000

Part 24 of the memory benchmark series. Assumes familiarity with JVM memory regions and container memory limits.

96% at Idle

Quarkus JVM, jdbc-synth scenario, 256 MB container (--memory=256m, swap disabled). The app starts. Prometheus reports heap usage: 37 MB used out of a 62 MB cap. Healthy. Normal. Unremarkable.

Container RSS at idle: 246 MB.

The first k6 ramp hits, allocates a few buffers, and the OOM killer fires. Twenty-six restarts. 42.8 req/s. 53% error rate. FAILED.

Every Route Registered. Every Request 404'd.

Mon, 06 Jul 2026 00:00:00 +0000

Thirty-three routes registered. Startup log confirms it. The /routes management endpoint lists every one. And under load, every single request returns 404.

This is the reactive Micronaut branch of the space observatory benchmark — 28 upstream API calls, 10 HTTP clients, all pointed at a Go mock server that deliberately injects failures (HTTP 500, 504-after-delay, abrupt connection close). The imperative sibling branch works. The lighter synth variant works. This one: 100% 404.

Three Front Doors, One Engine

Sun, 05 Jul 2026 00:00:00 +0000

Part 22 of the Micronaut native image series. Follows Part 21, where a retry was mistranslated two ways. Assumes familiarity with reactive Java (Mono/Flux/Uni) and at least one of the three frameworks.

The experiment

Same app. Same Java 25. Same GraalVM CE 25. Same Postgres. Same Liquibase schema. Same benchmark harness. Three frameworks.

The app fans out to 28 HTTP APIs concurrently, computes risk scores across seismic, atmospheric, and space weather data, and writes one row to Postgres. Six endpoints. The heaviest hits all 28 APIs in four parallel blocks. Built on Micronaut 5.0.0 with reactive R2DBC. Ported to Spring Boot 4.1 and Quarkus 3.33.

Quarkus 12,563 vs Spring 820 (Both Numbers Are Wrong)

Fri, 03 Jul 2026 00:00:00 +0000

Part 18 of the Micronaut native image series. Follows Part 17, which found that reactive and imperative hit the same throughput ceiling. Assumes familiarity with Prometheus counters.

Two numbers that can’t both be right

The framework comparison benchmark finished. Three frameworks, same app, same k6 profile, same 256 MB native image container. The analysis script printed:

Spring Boot:  HTTP served:  820 requests   avg=2.341ms
Quarkus:      HTTP served:  12,563 requests  avg=1.892ms

Quarkus crushes Spring by 15x. Write the blog post. Ship the chart.

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.

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.

Every GC Failed at 256 MB (Except the Boring One)

Sun, 31 May 2026 00:00:00 +0000

Monday: “The JVM at 256 MB should work. Just need the right GC.”

Tuesday: G1GC. OOM at 150 concurrent users.

Tuesday, later: Shenandoah. OOM at 50 concurrent users.

Tuesday, even later: ZGC. OOM at zero concurrent users. Couldn’t serve a single request.

Wednesday: Serial GC with 7 JVM flags and 3 Micronaut properties. Survives 60 seconds before the OOM killer shows up anyway.

The Contenders

Same app: Micronaut 5.0.0 Space Observatory, 16 REST endpoints, reactive R2DBC, 7-table PostgreSQL schema. Container: 256 MB hard limit, swap disabled. Heap capped at 64 MB (-Xms64m -Xmx64m). Load: k6, ramping from 10 to 200 concurrent users over 8.5 minutes.

Native Image vs JVM at 128 MB: The Benchmark Nobody Warned Me About

Tue, 26 May 2026 00:00:00 +0000

The mental model: native image uses less memory, therefore native image performs better under memory pressure.

This is wrong.

Setup

The app: Micronaut 5.0.0 Space Observatory. 4 HTTP clients, reactive R2DBC into PostgreSQL, 7-table schema, 16 REST endpoints. Real enough to matter. (Part 1 covers the build.)

Four scenarios, clean database each time (docker compose down -v):

Native, unlimited memory – baseline
Native, 128 MB hard limit – mem_limit: 128m, swap disabled
JVM, unlimited memory – same app, java -jar
JVM, 128 MB hard limit – same container constraint

Load: Apache Bench, 1,000 requests x 20 concurrent, container-to-container. DB endpoints only – no external API calls polluting the numbers. Host: 16 cores, 32 GB RAM, Linux 7.0.9.