Revamping the Performance that matters section

Signed-off-by: Michal Maléř <mmaler@redhat.com>

Author: MichalMaler

_posts/2025-11-04-mmaler-blogpost-2-quarkus-runtime-and-framework-for-cloud-native-java.adoc

@@ -84,28 +84,28 @@ These features give developers structure, sensible defaults, and clear conventio
 
 === Performance that matters
 
-In practice, the two goals that matter most for production-grade frameworks at scale are fast startup and resilience against cascading failures.
-Rapid startup improves elasticity and recovery, while resilience prevents local faults from spreading and enables services to handle failures gracefully.
-For a broader industry perspective, see the link:https://cacm.acm.org/practice/application-frameworks/[ACM article on application frameworks].
+Teams optimize for different goals, such as startup latency, sustained throughput, memory footprint, elasticity, and cost.
+Quarkus addresses these needs by shifting work from run time to build time, keeping one development model across JVM and native, and exposing production signals such as health checks, metrics, and tracing.
 
-Quarkus shifts work from runtime to build time, thus enabling faster cold starts.
-Additionally, it offers the option to generate native executables with GraalVM's native-image, enabling cold starts in milliseconds and a minimal memory footprint.
-This results in higher pod density, quicker horizontal scaling, and lower idle costs.
-As such, it enables cost-effective deployment in containers and serverless environments.
+Start with **JVM mode** for most services.
+It starts slower and uses more memory than native to start with, but just-in-time compilation raises steady-state throughput, scales well across cores, and offers mature garbage collectors and tuning options.
+Quarkus can often start faster on the JVM than typical Spring Boot setups under comparable conditions because more work happens at build time.
 
-Native images often provide faster startup and lower RSS. However, they can deliver lower peak throughput and exhibit scaling limits on multi-core machines.
-Current native images typically use a single-threaded garbage collector, which is inefficient for large heaps and does not benefit from multiple cores.
-We generally recommend native execution for services that run on smaller instances, up to 2 vCPUs with roughly 2-4 gigabytes of RAM, where startup time and memory footprint dominate cost and user experience.
+Use **native mode** when startup latency and memory footprint are strict constraints.
+Native executables start in milliseconds and can use less memory, which supports scale-to-zero workflows and lowers idle costs on small instances.
+Trade-offs include lower peak throughput, limited multi-core scaling, a single-threaded garbage collector in current native images, longer build times, and a slower inner loop for developers.
 
-JVM execution, by contrast, takes longer to start and warm up.
-However, it can achieve higher peak performance through just-in-time compilation. It also scales well beyond two cores and it offers more capable garbage collectors and tuning options.
+If your system needs both profiles, split by workload.
+Run bursty or event-driven endpoints in native mode, and run long-lived high-throughput services on the JVM.
 
-Choose the mode that matches your workload profile, cold-start targets, and cost envelope, and let Quarkus maintain a consistent development model across both paths.
+**Observability note.**
+JVM mode exposes richer diagnostics and metrics, including GC, heap, and thread telemetry, JFR, and profiler support, which makes issue triage and performance tuning easier.
+Native mode still exports application-level metrics and traces with Micrometer and OpenTelemetry, but it offers fewer VM-level signals.
 
-* If you optimize for native execution, audit reflection and resource usage, enable dead-code elimination-friendly patterns, and consider profile-guided optimizations where appropriate.
-* If you optimize for JVM execution, budget for warm up, enable the right GC for your heap and latency goals, and measure steady-state throughput under realistic load.
+Always measure your workload:
 
-Quarkus also includes structured health checks, metrics, and tracing, which align the runtime with production standards from day one.
+* For native, reduce reflection and dynamic class loading, trim resources, and consider profile-guided optimizations (PGO) where supported. PGO is not available in Mandrel and currently requires an Oracle GraalVM distribution that provides PGO.
+* For the JVM, choose a garbage collector that matches your latency and heap goals, budget for warmup, and test steady-state throughput under realistic load.
 
 Taken together, these in production choices provide measurable wins: