Understanding ReadyNow Orchestrator Generations

Table of Contents

Configuring Generations
Basic Profile Recording with Default Generations
Capping Profile Log Recording and Maximum Generations
Priority of Generation Settings

Need help?

Schedule a consultation with an Azul performance expert.

When using ReadyNow, you get the best results if you perform several training runs of your application to generate an optimal profile. For example, to generate a good profile for an application instance called MyApp-v1.5, you perform three training runs of your application to record three generations of the ReadyNow profile log. For each training run, you read in the generation recorded by the last training run as the input profile for the current training run.

You want to make sure that the output of each training run meets minimum criteria to be promoted as the input for the next level. These promotion criteria can be:

The duration (time) of the training run
The size of the candidate profile log

The ReadyNow Orchestrator feature in Optimizer Hub automatically takes care of creating a promoted profile as you run your application. Users specify the promotion criteria for each version of their application and a unique ProfileName as Java command line parameters. Administrators can also specify server-side global promotion criteria that must also be met. When deploying a new version of an application, ReadyNow Orchestrator automatically collects candidates from many JVMs running the same ProfileName and performs the training runs to generate the best promoted profile.

Configuring Generations

ReadyNow Orchestrator allows you to set different minimum size and recording durations for different generations of your profiles. Often you want to promote the first generation of your profile as quickly as possible so new JVMs are not starting with nothing, but you want your second generation to record for a longer time before promotion, so it is more complete.

You can use configuration settings for both ReadyNow Orchestrator itself and the JVM clients to change this behavior if the default values don’t deliver the desired result.

Basic Profile Recording with Default Generations

In its most basic form, you let the defaults do all the work. By default, ReadyNow Orchestrator nominates profile logs after three full generations and doesn’t place a limit on log size. Suppose you want to record a new profile while deploying code to a fleet running in production. Run with the following options:

 java -XX:OptHubHost={host:port} \
    -XX:+EnableRNO \
    -XX:ProfileName=opthub://MyApp-v3 \
    -jar myapp.jar

In this case, all JVMs nominate their logs based on the defaults (e.g. 2 minutes for the first generation, 10 minutes for the second generation, 120 minutes for the third generation) and keep recording until the JVM shuts down. For best results, do a test run in a canary instance for at least two minutes and if possible a full ten minutes. This creates generation 1 of your profile. Then restart your fleet as normal. As JVMs start up, they receive a profile from ReadyNow Orchestrator and check the generation number. If that number is less than the server-side default maximum of 3, the JVM writes out the next generation of the profile. Once there is a valid generation 3 of the profile on ReadyNow Orchestrator, none of the JVMs write any more output.

You can overrule the server-side defaults, by providing extra options, for example:

 java -XX:OptHubHost={host:port} \
    -XX:+EnableRNO \
    -XX:ProfileName=opthub://MyApp-v3 \
    -XX:ProfileLogOutNominationMinSizePerGeneration=0:1000000\,1:10000000\,2:25000000\,3:50000000 \
    -XX:ProfileLogOutNominationMinTimeSec=0:PT2M\,1:PT15M\,2:PT30M\,3:PT60M \
    -jar myapp.jar

Capping Profile Log Recording and Maximum Generations

We can make our example above more complex:

After 10 minutes you want to stop recording.
You want to record two generations of the profile.

Start your JVM with the following parameters:

 java -XX:OptHubHost={host:port} \
    -XX:+EnableRNO \
    -XX:ProfileName=opthub://MyApp-v3 \
    -XX:ProfileLogTimeLimitSeconds=600 \
    -XX:ProfileLogOutMaxNominatedGenerationCount=2 \
    -jar myapp.jar

Priority of Generation Settings

Please take the default values into account when you define your own generation settings as these can be overruled by other default settings. Let’s look at an example:

You define -XX:ProfileLogOutNominationMinTimeSec=900, but don’t change other settings.
The server-side default for the promotion of different generations, specifies the following default 0:PT2M\,1:PT15M\,2:PT30M\,3:PT60M for readyNowOrchestrator.promotion.minProfileDurationPerGeneration.
As a result, the 2nd and 3rd generation aren’t promoted after 900 seconds, but after 30 and 60 minutes as specified in the defaults.

When you want to overrule the default settings, make sure to specify all appropriate options.