Vertical scaling is not a replacement for horizontal scaling. It is a complement. Horizontal scaling determines how many replicas you need. Vertical scaling\u00a0determines\u00a0how much CPU and memory each replica should have at\u00a0different phases\u00a0of its lifecycle.\u00a0<\/p>\n\n\n\n
In this post, we focus on a common vertical scaling challenge: Java warm-up<\/strong>. <\/p>\n\n\n\n One of the key concepts of a JVM, so called Just-In-Time (JIT) compilation, is the ability to continuously optimize the source code based on the actual data being processed and code paths being executed. The benefit of this approach, compared to static code compilation in programming languages like C\/C++, is that it\u00a0ultimately yields\u00a0higher peak performance, or from the opposite angle, needs\u00a0less\u00a0resources to handle the same load.\u00a0<\/p>\n\n\n\n Due to the JIT compilation, Java Virtual Machines, and thus Java applications, do not have a single stable resource footprint during the whole lifecycle of the application. In simple terms, the application starts \u201cslow\u201d, then is continuously optimized by the JIT compiler until it reaches the \u201csteady state\u201d where the application is running in fully optimized machine code, showing the best possible throughput and latency. The part of getting to \u201csteady state\u201d is referred to as warm-up<\/strong> and the fundamental trade-off is that the JIT compiler consumes (one time, typically) extra CPU to perform the optimizations. <\/p>\n\n\n\n Warm-up happens every time the application is newly started. In the modern Kubernetes world, this is more than common \u2013 horizontal autoscaling, spawning new instances and stopping the unnecessary ones dynamically based on load, has become the new standard of running things cost efficiently. <\/p>\n\n\n\n If you size a Kubernetes pod<\/a> only for steady state usage, warm-up takes longer. The service may begin receiving traffic while still cold (code is not fully optimized yet) and, even worse, the service is competing for CPU with the JIT compiler. Together, this often leads to unstable latency and poor early performance. <\/p>\n\n\n\n On the other hand, allocating enough CPU permanently to comfortably handle the warm-up phase wastes cluster capacity. It\u2019s common that the container utilizes almost all of the available CPU just in the first few minutes (during warm-up), but when steady state is reached, the traffic can be easily handled with, e.g., 50% of the available CPU. In summary, this leads to overprovisioning and in the end, waste of money. <\/p>\n\n\n\n The right model is simple and intuitive: allocate more CPU during warm-up, then reduce the allocation once the JVM is fully optimized<\/strong>. <\/p>\n\n\n\n Azul Zing, the JVM at the heart of Azul Prime, is the first JVM on the market to integrate directly with Kedify, making this kind of lifecycle-aware right-sizing seamless and trivial to use. <\/p>\n\n\n\n What is Azul Prime?<\/strong> <\/p>\n\n\n\n Azul Prime is a high-performance JVM platform and a drop-in replacement for OpenJDK HotSpot: same APIs, same TCK compliance, no application changes. Three orthogonal performance technologies set it apart: <\/p>\n\n\n\n Combined with the optional Optimizer Hub service (Cloud Native Compiler offloads JIT compilation to a dedicated service; ReadyNow Orchestrator manages profiles across an entire JVM fleet), Azul Prime targets two complementary goals: better, more predictable performance for latency-sensitive Java workloads (financial trading, e-commerce, real-time analytics, Kafka pipelines) and meaningful infrastructure savings on Java workloads more generally, since the same load runs on materially fewer cores. <\/p>\n<\/blockquote>\n\n\n\n Kubernetes introduced In Place Pod Resource Resize<\/a> in v1.27, enabled by default since v1.33. This allows CPU and memory requests and limits to be updated for a running container without restarting the pod. <\/p>\n\n\n\n Kedify PodResourceProfiles<\/a> (PRPs) build on top of this capability. <\/p>\n\n\n\n What is Kedify?<\/strong> <\/p>\n\n\n\n Kedify is an enterprise autoscaling platform built on KEDA, designed to make Kubernetes scaling predictable, efficient, and production-ready. <\/p>\n\n\n\n Key capabilities include: <\/p>\n\n\n\n Built by the creators of KEDA, Kedify helps teams improve performance and reliability while reducing infrastructure costs by 30\u201340%<\/strong> through smarter scaling. <\/p>\n<\/blockquote>\n\n\n\n A PodResourceProfile lets you define a future resource adjustment triggered by workload lifecycle events, such as when a container becomes ready. <\/p>\n\n\n\n This unlocks a lifecycle-aware vertical scaling pattern: allocate extra CPU only during warm-up, then automatically shrink back once the JVM is optimized. This is vertical autoscaling driven by workload lifecycle, not static requests or manual tuning. <\/p>\n\n\n\n Note: While warm-up resizing is a common use case, PRPs can also be triggered by other lifecycle or demand signals<\/a>, enabling vertical scale-up even when horizontal scaling is con=strained or replica count cannot increase. If we want to achieve fast vertical scaling based on the actual usage and not predefined triggers, we can leverage PodResourceAutoscalers<\/a> and even combine them with PRPs. <\/p>\n\n\n\n To resize resources correctly, we need a real signal that warm-up is complete. <\/p>\n\n\n\n Azul Prime exposes compilation activity through JMX (docs<\/a>): <\/p>\n\n\n\n This metric represents the depth of the compilation queue, in other words how much work is left to be optimized. Early in startup it is high. As the JVM finishes optimizing, the compilation queue depth drops and keeps low. <\/p>\n\n\n\n We use this metric as a readiness gate. <\/p>\n\n\n\n Below is the core logic of the readiness probe: <\/p>\n\n\n\n During warm-up, output looks like this: <\/p>\n\n\n\n Only when the queue depth falls (and stays) below the threshold Kubernetes considers the pod ready. This avoids routing traffic to a JVM that is technically running but not yet optimized. <\/p>\n\n\n\n You can notice an additional small but important detail – calling a method \u201cfinishWarm-up\u201d through JMX. This is another part of the unique tight integration specific to Azul Zing JVM. <\/p>\n\n\n\n When a JVM is started (HotSpot included), it sizes its internal thread pools (e.g. for JIT compiler, garbage collector etc.) according to the available CPU and this sizing is done at startup of the JVM. But that\u2019s no longer suitable for this case of vertical (down)scaling. If we reduced the available CPU post warm-up, but kept the original amount of e.g. compiler threads, a sudden spike in JIT activity (commonly caused by e.g. workload type shift) could cause the JVM to consume an inadequate amount of CPU, again affecting the application latency. <\/p>\n\n\n\n By calling Zing\u2019s \u201cfinishWarm-up\u201d method, Kedify is effectively signaling \u201clet\u2019s scale down\u201d, making the JVM to properly adjust the internal thread counts. <\/p>\n\n\n\n To demonstrate the effect clearly, we used the Renaissance<\/a> benchmarking suite from MIT, specifically the finagle-http benchmark. <\/p>\n\n\n\n This workload generates significant JIT activity by running many small HTTP requests against a Finagle server. It creates exactly the kind of warm-up pressure seen in real JVM services. <\/p>\n\n\n\n We deploy the workload with a high initial CPU allocation: <\/p>\n\n\n\n This ensures the JVM has enough compute to get through the compilations quickly. <\/p>\n\n\n\n We add a readiness (or it could be a startup probe) that queries the compilation queue depth through JMX. While the queue is still above the threshold, readiness fails and Kubernetes will not route traffic to the pod. <\/p>\n\n\n\n Once compilation activity settles, readiness succeeds and the pod becomes eligible for traffic. <\/p>\n\n\n\n It is important to note that probes only control traffic and restart behavior. Startup probes can delay restarts, but PodResourceProfiles are what actually resize CPU requests and limits in place once warm-up is finished. <\/p>\n\n\n\n Note: In the real world, the vast majority of JIT compilations\u00a0is\u00a0actually triggered once the load is being handled. So how can you finish warm-up before the readiness probe succeeds? First, the vertical scaling (and calling \u201cfinishWarm-up\u201d) is not tied to a readiness\u00a0probe,\u00a0it\u2019s\u00a0like this for the purpose of the demo. Therefore, you can succeed in a readiness probe, handle traffic for some time with extended\u00a0resources\u00a0and scale down later. While this approach already provides value (getting through warm-up\u00a0faster and having additional resources for the JIT compilation, minimizing the impact on application latency), it can be done even better.\u00a0<\/em><\/p>\n\n\n\n With Azul Zing JVM\u2019s\u00a0ReadyNow\u00a0technology (docs<\/a>), you can take this a step further. ReadyNow persists the compiler profile from previous\u00a0runs of the application, so a freshly started JVM\u00a0doesn\u2019t\u00a0have to discover its hot code paths from\u00a0scratch,\u00a0it can pre-compile the methods it knows will be needed, before the first request even arrives. Combined with\u00a0ReadyNow\u00a0Orchestrator, which collects and distributes optimization profiles across an entire fleet of JVMs, you can realistically reach near-steady-state performance during the warm-up window itself. By the time the readiness probe succeeds and traffic arrives, the JVM is genuinely ready to handle it at full speed, no early latency tax.\u00a0<\/p>\n\n\n\n Once readiness succeeds, Kedify applies a PodResourceProfile: <\/p>\n\n\n\n This transitions the pod from warm-up sizing to steady state sizing, without restart. <\/p>\n\n\n\n You can observe the change live: <\/p>\n\n\n\n PodResourceProfiles let you treat JVM warm-up as a short lifecycle phase that deserves temporary compute, and then automatically return to a lean steady state footprint. <\/p>\n\n\n\n With Azul Prime, compilation activity creates an early CPU burst. PRPs make that burst explicit: <\/p>\n\n\n\n Warm-up duration is workload dependent, but PRPs ensure you do not pay for warm-up CPU forever. Once optimization finishes, allocation returns to the steady state footprint automatically. <\/p>\n\n\n\n The outcome is straightforward: <\/p>\n\n\n\n A typical transition looks like: <\/p>\n\n\n\n The exact numbers depend on workload behavior, but the operational pattern is consistent: fast warm-up, readiness-gated traffic, and lean steady state sizing. <\/p>\n\n\n\n PodResourceProfiles solve the per container sizing problem, while horizontal autoscaling solves the replica count problem. They work best together. <\/p>\n\n\n\n Horizontal scaling adds new replicas early based on proactive demand signals such as request rate or message queue depth. This ensures capacity is created before CPU saturation becomes visible. <\/p>\n\n\n\n Each new Java pod still needs to warm up. PodResourceProfiles apply vertical resizing to every newly created pod, giving it elevated CPU during JVM compilation and optimization. Once the pod is truly ready, resources are automatically reduced to the steady state footprint. <\/p>\n\n\n\n In practice, the flow looks like this: <\/p>\n\n\n\n To experiment with this approach: <\/p>\n\n\n\n This gives you a declarative way to treat warm-up as a first class lifecycle phase rather than a permanent sizing decision. <\/p>\n\n\n\n Java warm-up is a distinct phase with distinct CPU requirements. Treating pod resources as static forces teams into a tradeoff between overprovisioning and degraded early performance. <\/p>\n\n\n\n With Azul Zing exposing JIT compilation progress, enabling reacting to changed resources and Kedify PodResourceProfiles enabling in place vertical scaling, Kubernetes can allocate extra CPU during warm-up and release it once the pod is truly ready. The result is faster startup, more stable latency, and better cluster efficiency in steady state. <\/p>\n\n\n\n If you run JVM services on Kubernetes, this is a pattern worth trying on a workload with noticeable warm-up behavior. Reach out to the Kedify team if you want help benchmarking or applying PodResourceProfiles in production. <\/p>\n\n\n\n Warm up fast. Serve traffic only when ready. Run lean afterward.<\/strong> <\/p>\n","protected":false},"excerpt":{"rendered":" Learn how to accelerate Java warm-up on Kubernetes with Azul Prime & Kedify.<\/p>\n","protected":false},"author":178,"featured_media":93356,"template":"","resource_categories":[774],"industry":[],"product":[280],"role":[43,44,57,61,62,64,69,282,710],"resource_topic":[273,775,776,777],"class_list":["post-93313","article","type-article","status-publish","has-post-thumbnail","hentry","resource_categories-java-warmup","product-prime","role-developer","role-cio-it","role-architect","role-cto","role-devops","role-head-of-engineering","role-vp-engineering","role-it-decision-maker","role-devops-operations","resource_topic-performance","resource_topic-java-warmup","resource_topic-kubernetes","resource_topic-kedify"],"acf":{"article_smart_summary":" In this post you will learn:<\/span><\/b>\u00a0<\/span><\/p>\n![\"\"](\"https:\/\/azul.imgix.net\/wp-content\/uploads\/Image-1-V2-scaled.png?auto=format&crop=faces,entropy&fit=max&q=80&w=739&s=9c9aec3269847bb00fdce6bae81d528a\")
<\/p>\n\n\n\n<\/a>Why JVM Warmup and Steady State Should Not Share the Same Resource Profile<\/h2>\n\n\n\n
Diagram #1: Relationship between application lifecycle, CPU spend by the JIT compiler, and performance<\/strong><\/h6>\n\n\n\n
![\"\"](\"https:\/\/azul.imgix.net\/wp-content\/uploads\/Image-2-1-scaled.png?auto=format&crop=faces,entropy&fit=max&q=80&w=739&s=3894c42765e21a1cc44c4d8df8c979a5\")
<\/p>\n\n\n\nDiagram #2: Warm-up phase vs steady state<\/strong><\/h6>\n\n\n\n
![\"\"](\"https:\/\/azul.imgix.net\/wp-content\/uploads\/Image-3-1-scaled.png?auto=format&crop=faces,entropy&fit=max&q=80&w=739&s=d624f67d80430309f25ce340c3f5151f\")
<\/p>\n\n\n\n\n
\n
<\/a>PodResourceProfiles: Vertical Scaling Without Restarts<\/h2>\n\n\n\n
\n
\n
<\/a>Measuring JVM Warm-up Using Azul Prime JMX Metrics<\/h2>\n\n\n\n
Bean: com.azul.zing:type=Compilation \nAttribute: TotalOutstandingCompiles <\/code><\/pre>\n\n\n\n\n\n\n\nCode Snippet: JMX Based Warm-up Probe<\/strong> <\/h4>\n\n\n\n
bean = \"com.azul.zing:type=Compilation\" \nattribute = \"TotalOutstandingCompiles\" \n\nvalue = conn.query([JMXQuery(bean, attribute=attribute)])[0].value \n\nif value < threshold: \n conn.invoke_operation(bean, \"finishWarm-up\", []) \n sys.exit(0) \nelse: \n sys.exit(2) <\/code><\/pre>\n\n\n\n\n\n\n\n\n\n786 \nTotalOutstandingCompiles still above threshold: 786 >= 500 <\/code><\/pre>\n\n\n\n\n\nDemo Workload: Forcing Heavy Warm-up<\/strong> <\/h4>\n\n\n\n
Step 1: Start With Elevated CPU<\/strong> <\/h4>\n\n\n\n
resources: \n requests: \n cpu: 10 \n limits: \n cpu: 10 <\/code><\/pre>\n\n\n\n\n\nStep 2: Delay Readiness Until Warm-up Completes<\/strong> <\/h4>\n\n\n\n
Step 3: Shrink CPU Automatically with PodResourceProfiles<\/strong> <\/h4>\n\n\n\n
apiVersion: keda.kedify.io\/v1alpha1\nkind: PodResourceProfile \nmetadata: \n name: heavy-workload \nspec: \n target: \n kind: deployment \n name: heavy-workload \n containerName: main \n trigger: \n after: containerReady \n delay: 0s \n newResources: \n requests: \n cpu: \"4\" \n limits: \n cpu: \"4\" <\/code><\/pre>\n\n\n\n\n\nkubectl get po -lapp=heavy-workload \\ \n -ojsonpath=\"{.items[*].spec.containers[?(.name=='main')].resources}\" | jq <\/code><\/pre>\n\n\n\n\n\nDiagram #3: Resource transition timeline<\/strong> <\/h6>\n\n\n\n
![\"\"](\"https:\/\/azul.imgix.net\/wp-content\/uploads\/Image-4-2-scaled.png?auto=format&crop=faces,entropy&fit=max&q=80&w=739&s=07e91025e7e8553103fdb5a66db5fd4e\")
<\/p>\n\n\n\n<\/a>Metrics: What This Achieves<\/h2>\n\n\n\n
\n
\n
\n
<\/a>How Vertical and Horizontal Scaling Work Together<\/h2>\n\n\n\n
\n
![\"\"](\"https:\/\/azul.imgix.net\/wp-content\/uploads\/Image-5-1-scaled.png?auto=format&crop=faces,entropy&fit=max&q=80&w=739&s=5202a8c01a0ddbd87a0da47a64ef6a14\")
<\/p>\n\n\n\n<\/a>Try It Yourself<\/h2>\n\n\n\n
\n
<\/a>Closing Thoughts<\/h2>\n\n\n\n
\n