Performance on tsvinc

Four Bugs the Tests Couldn't See

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

Part 24 of the memory benchmark series. Follows Part 23, where six HTTP client swaps each OOM’d differently. Assumes familiarity with R2DBC, Hibernate Reactive, and connection pooling.

The senior code review on the first reactive port – Spring Boot 4.1 WebFlux and Quarkus 3.33 Hibernate Reactive, same app, same tests – came back clean. Field mapping: correct. Fan-out concurrency: correct. Scoring logic: correct. Native image hints: correct. Retry semantics: fixed (that was Part 21). All tests green.

Six OOMs and a Connection Pool

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

Part 23 of the Micronaut native image series. Follows Part 22, where the reactive ports reached throughput parity across three frameworks. Assumes familiarity with Spring’s RestClient and GraalVM native image.

The same 28-API fan-out app runs comfortably at 256 MB on Quarkus. Runs comfortably on Micronaut. On the imperative Spring Boot 4.1 port – Spring MVC, virtual threads, JdbcClient – it OOM’d. Then I fixed it and it OOM’d differently. Six benchmark runs. Six different failure modes. Each one peeling back a layer of what “choosing an HTTP client” actually means in a memory-constrained native image.

1% CPU and 6-Second Latency

Sat, 04 Jul 2026 00:00:00 +0000

Part 20 of the Micronaut native image series. Follows Part 19, where a native image OOM’d at 256MB. Assumes familiarity with reactive Java and connection pooling.

Quarkus 3.33. Hibernate Reactive Panache. Mutiny. GraalVM native image in a 256MB container. Six endpoints, each fanning out to 28 mock APIs via Uni.combine, computing risk scores, persisting one row. The near-identical Spring WebFlux port did 100 req/s.

Quarkus did 18.8.

Average latency: 6.4 seconds. p95: 16 seconds. 33% of k6 checks failing. And the CPU was at 1%.