Visit Azul.com Support

Using Compilation Streaming

Table of Contents
Need help?
Schedule a consultation with an Azul performance expert.
Contact Us

Compilation Streaming lets a JVM download a stream of previously performed compilations from Optimizer Hub at startup and install them directly, instead of requesting each compilation individually as the application warms up. This shortens the time needed to clear the compilation queue and reduces load on Cloud Native Compiler.

Optimizer Hub builds each stream from its Code Cache and the promoted ReadyNow profile for a given profile name. Stream generation is automatic: when a profile is promoted, Optimizer Hub records a build request and the task-executor component produces the stream. At startup a JVM asks whether a stream exists for its profile. If one does, the JVM uses it. If not, the JVM runs normally without streaming and no error is reported.

Because promotion is what triggers a stream build, no stream exists for a profile name until a profile has been promoted for it. See Compilation Streaming Requires a Promoted Profile.

Compilation Streaming requires Azul Zing 26.08.1.0 or later on the client side, and must be enabled on both the server and the JVM. On the JVM, add -XX:+CNCEnableCompilationStreaming. See Command Line Options in the Azul Prime documentation for the other JVM options that control it.

Tip
 For the complete Helm and JVM commands to enable Compilation Streaming on a new or existing installation, see Installing Optimizer Hub with Compilation Streaming.

Enabling Compilation Streaming

Compilation Streaming requires one setting in your values-override.yaml:

 
compilationStreaming:
  enabled: true

compilationStreaming.enabled turns on the feature and its endpoints. The task-executor pod that builds the streams is deployed by default, so no second setting is needed.

This setting mirrors the values-comp-stream.yaml file shipped with the Helm chart, which you can pass to helm install or helm upgrade instead.

Important
 If you disabled task-executor in your values-override.yaml, re-enable it with taskExecutor.enabled: true. Without it, the streaming endpoints start correctly but no streams are ever built, and JVMs continue without streaming and without reporting an error.

Configuration Options

Name Type Default Description

compilationStreaming.enabled

boolean

false

Enables Compilation Streaming. Optimizer Hub builds streams from Code Cache and ReadyNow Orchestrator content, and the gateway’s streaming endpoints become available. Requires taskExecutor.enabled, which is true by default.

taskExecutor.enabled

boolean

true

Deploys the task-executor pod, which builds streams from Code Cache content and the promoted ReadyNow profile. Without it, stream build requests are recorded but never executed.

compilationStreaming.eviction.enabled

boolean

true

Evicts stale compilation stream build requests.

compilationStreaming.eviction.buildRequestRetention

duration

P7D

How long a stream build request is retained before eviction, in ISO-8601 duration format. Applies only when compilationStreaming.eviction.enabled is true.

By default, the task-executor pod is sized at 4 CPU and 16 GiB of memory, with 10 GiB of ephemeral storage for temporary stream files. It is a fixed-size component that does not autoscale, and its cores are included in the simpleSizing vCore budget. See How Optimizer Hub Scales.

Storage Requirements

Stream segments are held in blob storage alongside your existing Code Cache and ReadyNow profile data, so you need to allow for additional capacity when you enable the feature. See Storage Requirements for sizing guidance.

Stream Segments

A stream is divided into segments, and a JVM holds a limited number of segments in memory at any one time. The default segment size is 500 compilations. You do not need to configure segmentation, as Optimizer Hub produces segmented streams automatically.

If a specific workload needs a different segment size, you can override it per build using the maxCompilationsPerSegment builder option when submitting a stream build request.

On the client side, the number of segments held in memory at once is controlled by -XX:CNCCompilationStreamingMaxActiveSegments. Larger values raise the hit rate slightly at a significant cost in JVM memory, so a value of 3 to 5 suits most production workloads.

Compilation Streaming and Indirect Delivery

A single JVM cannot use both Compilation Streaming and Indirect Delivery of ReadyNow profiles. You can leave both features enabled on the Optimizer Hub server. Each JVM resolves the conflict for itself at startup:

  • If -XX:RNOProfileTransportPriority is left at its default, the JVM prints a warning and sets the transport to grpc. Compilation Streaming is used, and the profile arrives over gRPC.

  • An explicit -XX:RNOProfileTransportPriority=uri causes a startup error.

  • An explicit -XX:RNOProfileSource=fallback causes a startup error.

If you adopted Indirect Delivery to reduce gateway traffic, enabling Compilation Streaming returns profile transport to gRPC. Account for that when sizing your Optimizer Hub connection.

Monitoring

Optimizer Hub records the following metrics for Compilation Streaming:

Metric Description

compstream.delivery.requests

Number of stream delivery requests received from JVMs.

compstream.delivery.duration

Time taken to serve stream delivery requests.

compstream.build.task.duration

Time taken to build a stream.

compstream.build.file.size

Size of the streams that were built.

compstream.queue.requests.total

Total number of stream build requests queued.

compstream.queue.wait.duration

Time that build requests spend waiting in the queue.

On the client side, streaming statistics appear in the JVM’s GC log in the COMPSTREAMSTATS line, covering lookups, hits, misses, installation outcomes, segments loaded and evicted, and bytes downloaded. The hit rate derived from these values is the main indicator of whether streaming is working well for an application.