-
Notifications
You must be signed in to change notification settings - Fork 380
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
4a7305f
commit b86244b
Showing
2 changed files
with
81 additions
and
60 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,64 +1,85 @@ | ||
<div class="full-width-bg component"> | ||
<div class="grid-wrapper"> | ||
<div class="width-3-12 width-12-12-m img-vert-center"> | ||
<img class="light-only" src="{{site.baseurl}}/assets/images/performance/icon-performance.svg" alt="Performance icon"> | ||
<img class="dark-only" src="{{site.baseurl}}/assets/images/performance/icon-performance-dark.svg" alt="Performance icon"> | ||
</div> | ||
<div class="width-9-12 width-12-12-m"> | ||
<h2>The Quarkus Way</h2> | ||
<p>Quarkus redefines Java development by shifting work to the build phase. This approach minimizes runtime dependencies, maximizes dead code elimination, and introduces clear metadata contracts, resulting in leaner and more efficient applications.</p> | ||
<p>The Quarkus approach helps to "strip out" all code which is only necessary to validate the user model</p> | ||
<ul> | ||
<li>compile classes or apply bytecode enhancements</li> | ||
<li>introspect in the model</li> | ||
<li>parse of framework configuration files</li> | ||
<li>discover extensions and services, or “apply auto-configuration"</li> | ||
</ul> | ||
<p>All that code is run only during the compilation phase; the classes don't even get loaded when the app is started. This means the JIT can make much better optimisations, and spend less memory in doing so.</p> | ||
<p>By performing these optimizations at build time, Quarkus ensures that the heavy lifting is done once, not at every startup, reducing memory usage and startup time.</p> | ||
<p>This approach benefits both GraalVM native images and traditional HotSpot JVM deployments, leading to faster, smaller, and more resource-efficient Java applications.</p> | ||
</div> | ||
<div class="width-3-12 width-12-12-m img-vert-center"> | ||
<img class="light-only" src="{{site.baseurl}}/assets/images/performance/icon-memory.svg" alt="Memory icon"> | ||
<img class="dark-only" src="{{site.baseurl}}/assets/images/performance/icon-memory-dark.svg" alt="Memory icon"> | ||
</div> | ||
<div class="width-9-12 width-12-12-m"> | ||
<h2>Reduced Memory</h2> | ||
<p>Quarkus reduces memory utilization for both traditional JVM deployments as well as native binaries using Ahead-of-Time (AOT) Compilation with GraalVM. In a traditional architecture many classes are loaded into memory, only to be pruned out later. Quarkus is able to avoid this wasted classloading. Quarkus also leverages build-time metadata processing, lowering memory consumption during execution.</p> | ||
</div> | ||
<div class="width-3-12 width-12-12-m img-vert-center"> | ||
<img class="light-only" src="{{site.baseurl}}/assets/images/performance/icon-startup.svg" alt="Startup icon"> | ||
<img class="dark-only" src="{{site.baseurl}}/assets/images/performance/icon-startup-dark.svg" alt="Startup icon"> | ||
</div> | ||
<div class="width-9-12 width-12-12-m"> | ||
<h2>Fast Startup Time</h2> | ||
<p>Quarkus delivers fast startup times that allow for automatic scaling up and down of microservices on containers or Kubernetes deployments. It achieves fast startup times by performing build-time processing for both JVM and native binary deployments, reducing the work done during runtime. Quarkus precomputes metadata and optimizes class loading, significantly cutting down on initialization time. For example, some frameworks do “auto-wiring” to external dependencies by attempting to load many possible implementations, using Java Reflection APIs. Quarkus is able to pre-wire in the dependency and bypass this rather slow process.</p> | ||
<p> For natively compiled binaries, Quarkus uses GraalVM to eliminate startup overhead resulting in near-instant startup times by running directly as a native executable.</p> | ||
</div> | ||
<div class="width-3-12 width-12-12-m img-vert-center"> | ||
<img class="light-only" src="{{site.baseurl}}/assets/images/performance/icon-throughput.svg" alt="Throughput icon"> | ||
<img class="dark-only" src="{{site.baseurl}}/assets/images/performance/icon-throughput-dark.svg" alt="Throughput icon"> | ||
</div> | ||
<div class="width-9-12 width-12-12-m"> | ||
<h2>Higher Throughput</h2> | ||
<p>Doing more work upfront at build time doesn’t just improve memory footprint and startup times. It also makes normal program execution faster. How? The output of a Quarkus build process is JIT-friendly, which means the JIT can make better optimizations, and get the application to a super-optimized state faster. For example, because there’s less unused bytecode in a Quarkus application, the JIT can inline more effectively. Early elimination of unused classes also enables the JVM to use monomorphic method dispatching, instead of the much slower megamorphic method dispatching. Megamorphic dispatching is necessary when there are several implementations of the same interface present on the classpath.</p> | ||
</div> | ||
<div class="width-3-12 width-12-12-m img-vert-center"> | ||
<img class="light-only" src="{{site.baseurl}}/assets/images/performance/icon-diskspace.svg" alt="Disk footprint icon"> | ||
<img class="dark-only" src="{{site.baseurl}}/assets/images/performance/icon-diskspace-dark.svg" alt="Disk footprint icon"> | ||
</div> | ||
<div class="width-9-12 width-12-12-m"> | ||
<h2>Disk Footprint</h2> | ||
<p>Quarkus reduces the footprint of Java applications by employing build-time processing to eliminate unnecessary runtime dependencies and by optimizing the application’s deployment artifacts. It packages only the essential classes and resources needed at runtime, removing unused code through techniques like dead code elimination. When using GraalVM for native compilation, Quarkus further reduces the footprint by compiling the application into a compact native binary, stripping out the JVM and related dependencies.</p> | ||
<p>Traditionally, when optimizing software performance, there is often a tradeoff between throughput and memory footprint, or between startup time and eventual throughput. In contrast, many of the Quarkus optimizations, such as dead code elimination, improve multiple aspects of application performance. The Quarkus way eliminates wasted work and results in a leaner application which both starts fast and runs fast, all while consuming less memory.</p> | ||
</div> | ||
<div class="width-12-12 width-12-12-m"> | ||
<h2>Related Links</h2> | ||
<p><a href="https://quarkus.io/blog/reactive-crud-performance-case-study/">"Reactive CRUD Performance: A Case Study" Blog Post</a><br> | ||
<a href="https://quarkus.io/guides/performance-measure">"Measuring Performance" guide</a> | ||
</p> | ||
</div> | ||
</div> | ||
<div class="width-12-12"> | ||
<p class="intropara">Quarkus is engineered for efficiency. It leverages build-time optimizations and a reactive core to achieve high throughput, fast startup times, low response latency, and minimal resource consumption. In other words, Quarkus is fast, and here is why; <strong>Reduced Memory Footprint, Fast startup Time and Higher Throughput</strong></p> | ||
<h2>Starting fast by doing less: the build-time principle</h2> | ||
</div> | ||
<div class="width-6-12 width-12-12-m"> | ||
<p>Quarkus redefines how Java applications are built and executed by shifting much of the work to the build phase ensuring that the costly work happens only once — during the build process — not at every startup. It results in faster, smaller, and more resource-efficient Java applications on both GraalVM native images and traditional JVM deployments.</p> | ||
<p>For example, at build time, Quarkus reads part of the application configuration, scans the classpath for annotated classes, and constructs a model of the application. By doing this early, Quarkus has enough information to eliminate unnecessary components and compute the exact startup instructions required.</p> | ||
</div> | ||
<div class="width-6-12 width-12-12-m img-vert-center"> | ||
<img class="light-only" src="{{site.baseurl}}/assets/images/container/build-time-principle-light.png" alt="Quarkus Build Time Principle" width="90%"> | ||
<img class="dark-only" src="../guides/images/build-time-principle.png" alt="Quarkus Build Time Principle" width="90%"> | ||
</div> | ||
<div class="width-12-12 width-12-12-m"> | ||
<p>This build-time optimization offers several key benefits:</p> | ||
<ol> | ||
<li><strong>Reduced startup time:</strong> Quarkus performs most of the heavy work at runtime, significantly cutting startup time and allowing the app to reach peak performance faster.</li> | ||
<li><strong>Lower memory consumption:</strong> By minimizing allocations and class loading, Quarkus reduces memory usage. Replacing reflection with build-time bytecode generation further lowers the JVM's runtime workload.</li> | ||
<li><strong>Better latency and improved throughput:</strong> Quarkus generates highly optimized code at build time and prunes unnecessary classes and methods. For instance, it weaves layers of indirection together, enabling better JIT optimizations. These improvements result in faster code and better latency. </li> | ||
</ol> | ||
</div> | ||
</div> | ||
</div> | ||
|
||
<div class="component-wrapper-slim"> | ||
<div class="width-12-12"> | ||
<h2>High concurrency without the headaches: the reactive core</h2> | ||
<p>Quarkus is built on reactive principles, using an efficient asynchronous, non-blocking engine based on Netty and Eclipse Vert.x. It employs a few event loops instead of a large thread pool, reducing resource usage and improving response times by optimizing for hardware behavior.</p> | ||
<p>Quarkus offers three development models:</p> | ||
<ol> | ||
<li><strong>Imperative model:</strong> A traditional synchronous approach with faster execution due to an optimized I/O layer, ideal for lower concurrency. High concurrency increases memory use.</li> | ||
<li><strong>Reactive model:</strong> Enables high concurrency with minimal resources using asynchronous, non-blocking code, but is more complex to implement and debug.</li> | ||
<li><strong>Virtual threads (JDK 21+):</strong> Combines the benefits of imperative and reactive models, allowing imperative code to run on lightweight virtual threads for high concurrency with low memory overhead, though some limitations remain.</li> | ||
</ol> | ||
</div> | ||
</div> | ||
|
||
<div class="component-wrapper options-band"> | ||
<div class="width-12-12"> | ||
<h2>What happens when the build time principle and the reactive core are combined?</h2> | ||
<p>The combination of the build time optimization and reactive core makes Quarkus a highly efficient framework, excelling in several key areas:</p> | ||
</div> | ||
<div class="width-3-12 width-12-12-m img-vert-center"> | ||
<img class="light-only" src="{{site.baseurl}}/assets/images/performance/icon-memory.svg" alt="Memory icon"> | ||
<img class="dark-only" src="{{site.baseurl}}/assets/images/performance/icon-memory-dark.svg" alt="Memory icon"> | ||
</div> | ||
<div class="width-9-12 width-12-12-m"> | ||
<h3>Reduced Memory</h3> | ||
<p>The build-time principle minimizes runtime memory use by eliminating unnecessary components and precomputing at build time, reducing class loading and memory allocations. The reactive core further cuts memory usage by using a few event loops instead of a large thread pool, allowing the application to handle higher loads with a smaller memory footprint and enabling high deployment density.</p> | ||
</div> | ||
<div class="width-3-12 width-12-12-m img-vert-center"> | ||
<img class="light-only" src="{{site.baseurl}}/assets/images/performance/icon-startup.svg" alt="Startup icon"> | ||
<img class="dark-only" src="{{site.baseurl}}/assets/images/performance/icon-startup-dark.svg" alt="Startup icon"> | ||
</div> | ||
<div class="width-9-12 width-12-12-m"> | ||
<h3>Fast Startup Time</h3> | ||
<p>Thanks to the build-time optimizations, most of the application’s heavy lifting, such as classpath scanning, configuration loading, and dependency injection setup, happens before the application even starts. This significantly reduces the time it takes to get the application up and ready to serve. The reactive core contributes to this by ensuring that I/O operations are handled with minimal blocking, further reducing the startup latency. The efficient startup process means the application can respond to new load conditions more quickly. This combination supports implementing LightSwitchOps patterns, enabling elasticity while controlling costs.</p> | ||
</div> | ||
<div class="width-3-12 width-12-12-m img-vert-center"> | ||
<img class="light-only" src="{{site.baseurl}}/assets/images/performance/icon-throughput.svg" alt="Throughput icon"> | ||
<img class="dark-only" src="{{site.baseurl}}/assets/images/performance/icon-throughput-dark.svg" alt="Throughput icon"> | ||
</div> | ||
<div class="width-9-12 width-12-12-m"> | ||
<h3>High Throughput</h3> | ||
<p>Build-time optimizations ensure tasks like classpath scanning, configuration loading, and dependency injection are completed before startup, greatly reducing startup time. The reactive core minimizes blocking in I/O operations, further lowering latency. This efficient startup enables quicker responses to load changes and supports LightSwitchOps patterns for cost-effective elasticity. </p> | ||
</div> | ||
<div class="width-3-12 width-12-12-m img-vert-center"> | ||
<img class="light-only" src="{{site.baseurl}}/assets/images/performance/icon-diskspace.svg" alt="Disk footprint icon"> | ||
<img class="dark-only" src="{{site.baseurl}}/assets/images/performance/icon-diskspace-dark.svg" alt="Disk footprint icon"> | ||
</div> | ||
<div class="width-9-12 width-12-12-m"> | ||
<h3>Optimized Resource Consumption</h3> | ||
<p>The build-time principle and reactive core optimize CPU, memory, and system resource use, enabling high performance with fewer resources. This lowers operational costs in cloud environments and offers sustainability benefits through reduced resource consumption.</p> | ||
</div> | ||
</div> | ||
<div class="component-wrapper"> | ||
<div class="width-12-12"> | ||
<h2>Continuously Measuring, Continuously Improving </h2> | ||
<p>Quarkus is dedicated to continuously improving performance, especially for code running on the critical execution (hot) path. Through ongoing optimizations, Quarkus ensures that every instruction and allocated byte matters, making it one of the most efficient frameworks available for developing <a href="https://www.techempower.com/benchmarks/#hw=ph&test=fortune§ion=data-r22&c=e&f=0-0-0-0-0-0-0-0-0-2-4zsow-0-0-0-0&l=5181v-6bl">high-performance, cloud-ready applications.</a></p> | ||
<h2>Related Links</h2> | ||
<p><a href="https://quarkus.io/blog/reactive-crud-performance-case-study/">"Reactive CRUD Performance: A Case Study" Blog Post</a><br> | ||
<a href="https://quarkus.io/guides/performance-measure">"Measuring Performance" guide</a></p> | ||
</div> | ||
</div> |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,7 +1,7 @@ | ||
--- | ||
layout: performance | ||
title: Quarkus Performance | ||
subtitle: Designed for speed and efficiency with minimal footprint. | ||
subtitle: Designed for Fast Startup, High Throughput, and Low Resource Consumption | ||
permalink: /performance/ | ||
--- | ||
|