Personnalisation du comportement de démarrage de l’environnement d’exécution Java pour les fonctions Lambda

Cette page décrit les paramètres spécifiques aux fonctions Java dans AWS Lambda. Vous pouvez utiliser ces paramètres pour personnaliser le comportement de démarrage de l'exécution Java. Cela permet de réduire le temps de latence et d'améliorer les performances globales de la fonction, sans avoir à modifier le code.

Comprendre la variable d'environnement JAVA_TOOL_OPTIONS

Sur Java, Lambda prend en charge la variable d'environnement JAVA_TOOL_OPTIONS pour définir des variables de ligne de commande supplémentaires dans Lambda. Vous pouvez utiliser cette variable d'environnement de différentes manières, par exemple pour personnaliser les paramètres de compilation par niveaux. L'exemple suivant montre comment utiliser la variable d'environnement JAVA_TOOL_OPTIONS pour ce cas d'utilisation.

Exemple : personnalisation des paramètres de compilation par niveaux

La compilation par niveaux est une fonctionnalité de la JVM (Java Virtual Machine). Vous pouvez utiliser des paramètres de compilation par niveaux spécifiques pour tirer le meilleur parti des compilateurs juste à temps (JIT) de la JVM. Généralement, le compilateur C1 est optimisé pour un démarrage rapide. Le compilateur C2 est optimisé pour obtenir les meilleures performances globales, mais il utilise également plus de mémoire et prend plus de temps pour y parvenir.

Il existe cinq niveaux différents de compilation par niveaux. Au niveau 0, la JVM interprète le bytecode Java. Au niveau 4, la JVM utilise le compilateur C2 pour analyser les données de profilage collectées lors du démarrage de l'application. Au fil du temps, elle surveille l'utilisation du code pour identifier les meilleures optimisations.

La personnalisation du niveau de compilation hiérarchisé peut vous aider à optimiser les performances de vos fonctions Java. Pour les petites fonctions qui s'exécutent rapidement, le réglage de la compilation hiérarchisée au niveau 1 peut contribuer à améliorer les performances de démarrage à froid en demandant à la JVM d'utiliser le compilateur C1. Ce paramètre produit rapidement un code natif optimisé mais ne génère aucune donnée de profilage et n'utilise jamais le compilateur C2. Pour les fonctions plus volumineuses nécessitant beaucoup de calculs, la définition de la compilation hiérarchisée au niveau 4 maximise les performances globales au détriment d'une consommation de mémoire supplémentaire et d'un travail d'optimisation supplémentaire lors des premiers appels après le provisionnement de chaque environnement d'exécution Lambda.

Pour les environnements d'exécution Java 11 et les versions antérieures, Lambda utilise les paramètres de compilation hiérarchisée JVM par défaut. Pour Java 17 et Java 21, Lambda configure la JVM pour arrêter la compilation hiérarchisée au niveau 1 par défaut. À partir de Java 25, Lambda arrête toujours la compilation hiérarchisée au niveau 1 par défaut, sauf lors de l'utilisation SnapStart ou de la simultanéité provisionnée, auquel cas les paramètres JVM par défaut sont utilisés.

Cela améliore les performances SnapStart et la simultanéité provisionnée sans entraîner de pénalité de démarrage à froid, car la compilation hiérarchisée est effectuée en dehors du chemin d'appel dans ces cas. Pour optimiser cet avantage, vous pouvez utiliser des chemins de code d'exécution d'amorçage lors de l'initialisation de la fonction pour déclencher JIT avant de prendre le SnapStart snapshot ou lorsque les environnements d'exécution de Provisioned Concurrency sont pré-provisionnés. Pour plus d'informations, consultez l'article de blog Optimisation des performances de démarrage à froid de AWS Lambda à l'aide de stratégies d'amorçage avancées avec. SnapStart

Pour personnaliser les paramètres de compilation par niveaux (console)

1. Ouvrez la page Fonctions de la console Lambda.

2. Choisissez une fonction Java pour laquelle vous souhaitez personnaliser la compilation par niveau.

3. Choisissez l'onglet Configuration, puis Variables d'environnement dans le menu de gauche.

4. Choisissez Modifier.

5. Choisissez Ajouter une variable d’environnement.

6. Pour Nom de la clé, saisissez JAVA_TOOL_OPTIONS. Pour Valeur, saisissez -XX:+TieredCompilation -XX:TieredStopAtLevel=1.

   

7. Choisissez Enregistrer.

Note

Vous pouvez également utiliser Lambda SnapStart pour atténuer les problèmes de démarrage à froid. SnapStartutilise des instantanés mis en cache de votre environnement d'exécution pour améliorer de manière significative les performances de démarrage. Pour plus d'informations sur les SnapStart fonctionnalités, les limites et les régions prises en charge, consultezAméliorer les performances de démarrage avec Lambda SnapStart.

Exemple : personnalisation du comportement de GC à l'aide de JAVA_TOOL_OPTIONS

Les exécutions Java 11 utilisent le récupérateur de mémoire (GC) Serial pour la récupération de mémoire. Par défaut, les exécutions Java 17 utilisent également le GC Serial. Toutefois, avec Java 17, vous pouvez également utiliser la variable d'environnement JAVA_TOOL_OPTIONS pour modifier le GC par défaut. Vous pouvez choisir entre le GC Parallel et le GC Shenandoah.

Par exemple, si votre charge de travail utilise davantage de mémoire et plusieurs UC, envisagez d'utiliser le GC Parallel pour de obtenir de meilleures performances. Vous pouvez le faire en ajoutant ce qui suit à la valeur de votre variable d'environnement JAVA_TOOL_OPTIONS :

-XX:+UseParallelGC

Si votre charge de travail comporte de nombreux objets éphémères, vous pouvez bénéficier d'une consommation de mémoire réduite en activant le mode générationnel du ramasse-miettes Shenandoah introduit dans Java 25. Pour ce faire, ajoutez ce qui suit à la valeur de votre variable d'JAVA_TOOL_OPTIONSenvironnement :

-XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational

Patch Log4j pour Log4Shell

Les environnements d'exécution Lambda pour Java 8, 11, 17 et 21 incluent un correctif visant à atténuer la vulnérabilité Log4Shell (CVE-2021-44228) dans Log4j, un framework de journalisation Java populaire. Ce correctif entraîne une surcharge des performances de démarrage à froid. Si vous utilisez une version corrigée de Log4j (version 2.17.0 ou ultérieure), vous pouvez désactiver ce correctif pour améliorer les performances de démarrage à froid. Pour désactiver le correctif, définissez la variable d'AWS_LAMBDA_DISABLE_CVE_2021_44228_PROTECTIONenvironnement surtrue.

À partir de Java 25, les environnements d'exécution Lambda n'incluent plus le correctif Log4Shell. Vous devez vérifier que vous utilisez Log4j version 2.17.0 ou ultérieure.

Ahead-of-Time (AOT) et caches CDS

À partir de Java 25, le runtime Lambda inclut un cache Ahead-of-Time (AOT) pour le client d'interface d'exécution Java (RIC), un composant d'exécution qui interroge activement les événements provenant de l'API Lambda Runtime. Cela améliore les performances de démarrage à froid.

Les caches AOT sont spécifiques à une version de JVM. Lorsque Lambda met à jour le runtime géré, il met également à jour le cache AOT pour le RIC. Toutefois, si vous déployez vos propres caches AOT, ceux-ci peuvent être invalidés ou entraîner un comportement inattendu suite à une mise à jour d'exécution. Nous vous recommandons donc vivement de ne pas utiliser les caches AOT lorsque vous utilisez des environnements d'exécution gérés. Pour utiliser les caches AOT, vous devez déployer vos fonctions à l'aide d'images de conteneurs.

Les caches AOT ne peuvent pas être utilisés avec les caches CDS (Class Data Sharing). Si vous déployez des caches CDS dans votre fonction Lambda, Lambda désactive le cache AOT.