Compare Springboot WebFlux (need to optimize?)/ Quarkus (based on Eclipse Vert.x)

[skyblackhawk]

I see below situation when a microservice is critical and call DB or external services and log asyncronous of webflux respect Quarkus (based on Eclipse Vert.x competitor of Webflux):

Final Comparison Matrix

Scenario	Spring Boot WebFlux	Quarkus Reactive	Winner
Idle memory footprint	~512 MB RSS	~218 MB RSS	✅ Quarkus (-57%)
Garbage collection frequency	~1 GC / 10 min	~1 GC / 30 min	✅ Quarkus (3x rarer)
Throughput (cold start / burst)	~2,450 req/sec	~2,810 req/sec	✅ Quarkus (+15%)
Throughput (after 30min sustained)	+12% over Quarkus	Loses ground to JIT	✅ Spring Boot
DB simple reads (RPS)	~17,000	~27,000	✅ Quarkus (+45%)
DB complex joins / ORM	+18% over Quarkus	Underperforms	✅ Spring Boot
External HTTP calls	Equivalent	Equivalent	🟰 Tie
Backpressure under load	✅ Native (Reactor)	✅ Native (Mutiny)	🟰 Tie
Behavior under constrained K8s resources	Degrades early	Holds under pressure	✅ Quarkus
Startup time	~4.8s	~0.9s	✅ Quarkus
Logging / tracing overhead	Slightly higher	Lower class load	✅ Quarkus

Could Springboot WebFlux architect, developers and maintainers optimize code to have similar performance of Quarkus based on Vert.x in a PROD env?

Thanks a lot to optimize framework.

[skyblackhawk]

Ok I can solve all with below fixes in configurations and source code.

But if you have any ideas on automatic optimization to solve negative scenarios to evaluate from Springboot WebFlux Team (For example you can reccomend by Warning in startup: timing and buffer size for asybnc logger, ... to architect, developers, performance tester for any build to define correctly timing and buffer of async logger point 3 or set as default ReactorClientHttpConnector point 1. or for PROD or and left to decide them):

1. Runtime Classpath Loading — Spring's Original Sin
   Spring Boot WebFlux inherits the Spring Framework startup mechanism: all classpath scanning, dependency injection, AOP proxies, and reflection occur at runtime, each time the process starts. This consumes CPU and RAM in the first few seconds and leaves metadata structures in memory that are no longer needed after startup.
   Quarkus performs most of this work at compile time, not at runtime: the application is preprocessed and optimized before it runs. Java Code Geeks The result is that Quarkus arrives at the first request-ready state with only what it actually needs in memory, while Spring carries the burden of all the bootstrap machinery.

2. Reflection — the hidden cost of Spring
   Spring heavily uses the Java Reflection API for bean wiring, AOP, JSON serialization, and annotation management. Reflection comes at a cost: it prevents aggressive optimizations by the JVM, blocks native compilation, and increases the loaded class footprint.
   A Spring Boot REST API with minimal business logic and RDBMS connectivity typically loads tens of thousands of classes and consumes 300–500 MB of RAM at runtime. Wallarm Quarkus solves reflection at build time, generating direct bytecode instead of delegating to dynamic introspection.

3. ApplicationContext — Monolithic In-Memory Structure
   Spring WebFlux maintains a complete, reactive ApplicationContext in memory for the life of the process. This context includes the registry of all beans, filter chains, resolvers, converters, and proxies, even those never used in that particular deployment. This structure does not scale linearly with application complexity.
   Quarkus does not have a runtime equivalent to the ApplicationContext: the wiring is already resolved in the bytecode generated during build.

To solve it (not remove log. Insert a warning by springboot webflux if environment is production) using asyncronous writer on log file with a buffer on ram as ch.qos.logback.classic.AsyncAppender that can specify timing and buffer to tuning it for PROD env under pressure.

4. Reactor vs. Vert.x Event Loop Layer Overhead
   Spring WebFlux uses Project Reactor as a reactive library, which runs on a Netty event loop. Quarkus uses Vert.x directly as its native event loop, with Mutiny as a reactive API on top. The critical difference is that:

Reactor is a library that wraps Netty with an additional abstraction layer.
Vert.x is the runtime, not an abstraction on top of it.

This means that every Mono/Flux in WebFlux carries scheduling and operator chaining overhead that Quarkus/Vert.x handles with fewer indirections. In high-throughput scenarios, this adds up.

5. Behavior under limited resources — the thread pool collapse
   With 1 vCPU and 2 GB of RAM on ECS Fargate, Spring Boot WebFlux couldn't handle the load test. Quarkus handled the same load very well. To make Spring Boot perform, it was necessary to scale up to 2 vCPUs and 4 GB of RAM. Medium
   The cause isn't WebFlux itself, but the fact that Spring brings with it more fixed memory overhead and more infrastructure threads (Reactor scheduler, context thread pool, internal executors) that consume resources before the first request even arrives.

6. Garbage Collection — a consequence of all the above

With more classes loaded, more infrastructure objects in the heap, and more Reactor structures in flight, Spring WebFlux generates significantly more pressure on the GC. The practical result has already been mentioned: a GC every 10 minutes for Spring vs. every 30 minutes for Quarkus. Under sustained load, this means more frequent pauses that degrade the high latency percentiles (P95, P99)—exactly the values ​​that matter for critical microservice SLAs.

Where WebFlux Stands Still
It's fair to say, however, that this isn't a one-sided victory for Quarkus. Spring WebFlux catches up and surpasses Quarkus in two specific scenarios:

Sustained load over time: Spring's JIT accumulates runtime optimizations that Quarkus can't make, having moved everything to build time. After 30+ minutes of continuous load, Spring WebFlux regains its competitiveness in CPU throughput.
Complex ORM: Hibernate on Spring WebFlux, thanks to its mature layer and JIT optimizations on complex queries, surpasses Quarkus with Panache on complex joins.

The final critical point is that Quarkus' advantages are structural and constant (less RAM, less GC, startup, K8 density), while Spring WebFlux's advantages are conditional (JIT after warmup, mature ORM)—and depend on how long and under what type of load the service runs.

The solution of all by code (Can add a warning on startup Webflux for Production environment?):

Spring Boot WebFlux — Performance Optimization Guide

The following interventions are grouped into three categories: configuration, internal architecture, and JVM tuning.
All can be applied without rewriting existing business code.

---

1. Netty — Separate Server and Client Thread Pools

By default, WebFlux shares the same Netty event loop between the HTTP server and WebClient for outbound calls.
Configuring a dedicated ReactorResourceFactory for WebClient with its own LoopResources eliminates contention between inbound and outbound I/O. Zero impact on business code.
Java:

@Bean
public WebClient webClient() {
    LoopResources clientLoop = LoopResources.create("webclient-loop", 4, true);
    HttpClient httpClient = HttpClient.create()
        .runOn(clientLoop);
    return WebClient.builder()
        .clientConnector(new ReactorClientHttpConnector(httpClient))
        .build();
}

---

2. Correct Scheduler per Task Type

The event loop works at its best only when threads never block. Using the wrong scheduler is the primary cause of WebFlux degradation under load.

• Schedulers.boundedElastic() → for blocking I/O (JDBC, legacy REST calls)
• Schedulers.parallel() → for CPU-intensive tasks (fixed pool = available cores)

Action: audit all existing subscribeOn() / publishOn() calls and assign the correct scheduler per task type.

---

3. Operator Fusion in Project Reactor

Reactor can merge compatible contiguous operators (.map(), .filter(), .flatMap()) into a single internal operator,
eliminating intermediate objects and reducing GC pressure.
Fusion is broken by intermediate publishOn() or log() calls.

Action: Not remove log() from hot production paths and minimize intermediate publishOn() in reactive chains but use ch.qos.logback.classic.AsyncAppender defining queueSize max single messages evaluate how many log write on average your WebFlux application.
Setting up a Logback AsyncAppender solves the root problem without touching the WebFlux reactive code. The log() in Reactor chains stops blocking the event loop because the Vert.x or Netty thread dumps the event to the appender's queue (queueSize=10000 max 10000 logs message) and returns immediately, without waiting for the actual I/O write.
Setting neverBlock=true ensures that the thread never blocks even under peak loads, and discardingThreshold=0 ensures that no log messages are lost if you set to 20 means 20% you will lost log message as trace or debug or info but increase performance, reducing resources the choose is your:
In logback-spring.xml:

	<appender name="ASYNC_CONSOLE" class="ch.qos.logback.classic.AsyncAppender">
		<queueSize>10000</queueSize>
		<discardingThreshold>0</discardingThreshold>
		<includeCallerData>true</includeCallerData>
		<maxFlushTime>5000</maxFlushTime>
		<appender-ref ref="CONSOLE" />
		<neverBlock>true</neverBlock>
	</appender>
    	<root level="${LOG_LEVEL}">
		<appender-ref ref="ASYNC_CONSOLE" />
	</root>

---

4. Virtual Threads for Residual Blocking Code

Available from Spring Boot 3.2+ with a single configuration line.
Allows limiting physical JDBC connections to 50–100 while handling tens of thousands of concurrent transactions,
eliminating the "one thread per connection" bottleneck without rewriting any code.
In application.yaml or application.properties add:

spring:
  threads:
    virtual:
      enabled: true

{
...
    spring.threads.virtual.enabled=true
...
}

---

5. WebClient Connection Pool Tuning

The default Reactor Netty connection pool is often undersized for high-throughput microservices.
An undersized pool causes silent queuing that does not surface in logs but degrades P95/P99 latency under load.

ConnectionProvider provider = ConnectionProvider.builder("optimized-pool")
    .maxConnections(500)
    .pendingAcquireMaxCount(1000)
    .pendingAcquireTimeout(Duration.ofSeconds(5))
    .maxIdleTime(Duration.ofSeconds(20))
    .build();

---

6. GC Tuning — ZGC or Shenandoah

The default G1 GC is not optimized for latency-sensitive, high-throughput applications.
Switching to ZGC (Java 21+) or Shenandoah reduces GC pauses to under 5ms even under heavy load,
directly closing the documented GC frequency gap with Quarkus. Zero code impact.
JVM variable to choose best performance garbage collector for java:

-XX:+UseZGC -XX:MaxGCPauseMillis=5

---

7. GraalVM Native Image — Structural Intervention

The only intervention requiring a build pipeline change, with zero impact on business code.
Moves classpath scanning and reflection resolution to compile time — exactly what Quarkus does by design.
Eliminates the deepest architectural advantage of Quarkus: idle memory footprint and startup time.

Trade-off: longer build times; some dependencies may require manual reflection hints.

Add in pom.xml:

	<properties>
               ...
		<native-maven-plugin>0.11.4</native-maven-plugin>
               ...
	</properties>
	<dependencies>
               ...
	</dependencies>
	<build>
		<plugins>
			<plugin>
				<groupId>org.graalvm.buildtools</groupId>
				<artifactId>native-maven-plugin</artifactId>
				<version>${native-maven-plugin}</version>
			</plugin>
                        ...
			</plugin>
		</plugins>
	</build>

---

Optimization Matrix

Intervention	Code Impact	Expected Gain	Difficulty
Separate Netty server/client thread pools	None	P99 latency -15/20%	Low
Correct scheduler per task type	Limited audit	Throughput +10/15%	Low
Operator fusion (remove intermediate logs)	Minimal	GC pressure -10%	Low
Virtual Threads for blocking code	None (config only)	Scalability under load	Very Low
WebClient connection pool tuning	None	P95/P99 -20%	Low
ZGC / Shenandoah	None (JVM flags only)	GC pauses < 5ms	Low
GraalVM Native Image	Build pipeline only	Idle footprint ≈ Quarkus	Medium

---

Conclusion

The first six interventions are purely configurative or JVM tuning, with no changes to business code.
Applied together, they close the majority of the documented structural gaps with Quarkus — GC frequency, idle memory footprint, and throughput under sustained load.
The seventh (GraalVM Native Image) is the only one requiring a build pipeline change,
but it eliminates the deepest architectural advantage of Quarkus by moving build-time processing out of runtime entirely.

[skyblackhawk]

If anyone has any tricks or magic tricks :), please comment here.
Thank you so much for your support.