Optimiser des applications Java

Ce guide décrit des optimisations pour les services Knative serving écrits dans le langage de programmation Java. Il présente également des informations générales pour vous aider à comprendre les compromis requis par certaines des optimisations. Les informations contenues sur cette page viennent en complément des conseils généraux d'optimisation, qui s'appliquent également à Java.

Les applications Web traditionnelles en langage Java sont conçues pour diffuser des requêtes avec une haute capacité de simultanéité et une faible latence. Il s'agit généralement d'applications à exécution longue. La JVM proprement dite optimise également le code d'exécution au fil du temps à l'aide de JIT, afin que les chemins d'accès les plus sollicités soient optimisés et que l'exécution des applications gagne progressivement en efficacité.

Un grand nombre de bonnes pratiques et d'optimisations de ces applications Web Java traditionnelles reposent sur les aspects suivants :

  • La gestion des requêtes simultanées (E/S non bloquantes et basées sur un thread)
  • La réduction de la latence de réponse à l'aide de fonctions non critiques de pooling des connexions et de traitement par lots, par exemple l'envoi de traces et de métriques à des tâches en arrière-plan

Bien que la plupart de ces optimisations traditionnelles fonctionnent bien pour les applications à exécution longue, il se peut qu'elles ne soient pas aussi efficaces dans un service Knative serving, qui ne s'exécute que lors de la diffusion active des requêtes. Cette page présente plusieurs optimisations et compromis spécifiques à Knative serving, que vous pouvez utiliser pour réduire le temps de démarrage et l'utilisation de la mémoire.

Optimiser l'image de conteneur

Optimiser l'image du conteneur peut vous aider à réduire les temps de chargement et de démarrage. Différentes actions vous permettent d'optimiser l'image :

  • Réduire l'image de conteneur
  • Éviter l'imbrication de fichiers JAR d'archives de bibliothèques
  • Utiliser Jib

Réduire l'image de conteneur

Consultez la page de conseils généraux visant à réduire la taille de l'image de conteneur pour obtenir davantage de contexte sur ce problème. Sur la page "Conseils généraux", nous vous recommandons de limiter le contenu des images de conteneurs aux seuls éléments indispensables. Par exemple, assurez-vous que votre image de conteneur ne contient pas les éléments suivants :

  • Code source
  • Artefacts de compilation Maven
  • Outils de compilation
  • Répertoires Git
  • Binaires/utilitaires non utilisés

Si vous compilez le code à partir d'un fichier Dockerfile, utilisez une compilation Docker en plusieurs étapes afin que l'image finale du conteneur n'héberge que le JRE et le fichier JAR de l'application en soi.

Éviter l'imbrication de fichiers JAR d'archives de bibliothèques

Certains frameworks courants, tels que Spring Boot, créent un fichier d'archive d'application (JAR) contenant des fichiers JAR supplémentaires pour les bibliothèques (fichiers JAR imbriqués). Ces fichiers doivent être décompressés lors du démarrage, ce qui peut augmenter la vitesse de démarrage dans Knative serving. Dans la mesure du possible, créez un fichier JAR léger avec des bibliothèques externalisées : vous pouvez automatiser cela en utilisant Jib pour conteneuriser votre application.

Utiliser Jib

Utilisez le plug-in Jib pour créer un conteneur minimal et désimbriquer automatiquement l'archive de l'application. Jib fonctionne avec Maven et Gradle, ainsi qu'avec les applications Spring Boot prêtes à l'emploi. Certains frameworks d'applications peuvent nécessiter des éléments de configuration supplémentaires pour Jib.

Optimiser la JVM

Optimiser la JVM pour un service Knative serving peut améliorer les performances et l'utilisation de la mémoire.

Utiliser des versions de JVM compatibles avec les conteneurs

Dans les VM et les machines, pour l'allocation du processeur et de la mémoire, la JVM identifie le processeur et la mémoire qu'elle peut utiliser à partir d'emplacements bien connus : sous Linux, il s'agit par exemple de /proc/cpuinfo et /proc/meminfo. Toutefois, lors de l'exécution dans un conteneur, les contraintes de processeur et de mémoire sont stockées dans /proc/cgroups/.... Une ancienne version du JDK continuera d'examiner /proc au lieu de /proc/cgroups, ce qui peut entraîner une utilisation du processeur et de la mémoire supérieure à la valeur allouée. Cela peut avoir les conséquences suivantes :

  • Un nombre excessif de threads, car la taille du pool de threads est configurée par Runtime.availableProcessors().
  • Un segment de mémoire par défaut qui dépasse la limite de mémoire du conteneur. La JVM utilise la mémoire de manière intensive avant de réaliser la récupération de mémoire. Cela peut facilement entraîner le dépassement de la limite de mémoire du conteneur et aboutir à un arrêt OOMKilled.

Vous devez donc utiliser une version de JVM compatible avec les conteneurs. Les versions d'OpenJDK supérieures ou égales à la version 8u192 sont par défaut compatibles avec les conteneurs.

Comprendre l'utilisation de la mémoire par la JVM

L'utilisation de la mémoire par la JVM se décompose en utilisation de la mémoire native et utilisation du tas de mémoire. La mémoire de travail de votre application se trouve généralement dans le tas de mémoire. La taille du tas de mémoire est limitée par la configuration du tas de mémoire maximal. Sur une instance Knative serving dotée de 256 Mo de RAM, vous ne pouvez pas allouer la totalité des 256 Mo au tas de mémoire maximal : en effet, la JVM et le système d'exploitation nécessitent également de la mémoire native, par exemple pour la pile de threads, les caches de code, les descripteurs de fichiers, les tampons de mémoire, etc. Si votre application subit un arrêt OOMKilled et que vous avez besoin de connaître l'utilisation de la mémoire par la JVM (mémoire native + tas de mémoire), activez le suivi de la mémoire native (Native Memory Tracking) pour observer les différentes valeurs d'utilisation lors d'un arrêt réussi de votre application. Si votre application subit un arrêt OOMKilled, elle ne sera pas en mesure d'imprimer ces informations. Dans ce cas, commencez par exécuter l'application avec davantage de mémoire, afin qu'elle puisse correctement générer la sortie.

Le suivi de la mémoire native ne peut pas être activé via la variable d'environnement JAVA_TOOL_OPTIONS. Vous devez ajouter l'argument de démarrage de ligne de commande Java au point d'entrée de votre image de conteneur, afin que votre application soit démarrée avec les arguments suivants :

java -XX:NativeMemoryTracking=summary \
  -XX:+UnlockDiagnosticVMOptions \
  -XX:+PrintNMTStatistics \
  ...

L'utilisation de la mémoire native peut être estimée en fonction du nombre de classes à charger. Envisagez d'utiliser un simulateur de mémoire Java Open Source pour estimer les besoins en mémoire.

Désactiver le compilateur d'optimisation

Par défaut, la JVM comporte plusieurs phases de compilation JIT. Bien que ces phases améliorent l'efficacité de votre application au fil du temps, elles peuvent également alourdir l'utilisation de la mémoire et allonger le délai de démarrage.

Pour les applications sans serveur et à exécution de courte durée (par exemple, les fonctions), envisagez de désactiver les phases d'optimisation : vous perdrez en efficacité à long terme, mais vous y gagnerez en termes de délai de démarrage.

Pour un service de diffusion Knative, configurez la variable d'environnement suivante :

JAVA_TOOL_OPTIONS="-XX:+TieredCompilation -XX:TieredStopAtLevel=1"

Utiliser le partage de données des classes d'application

Pour réduire davantage le temps JIT et l'utilisation de la mémoire, envisagez d'utiliser le partage de données des classes d'application (AppCDS, application class-data sharing) pour partager les classes Java compilées à l'avance en tant qu'archive. L'archive AppCDS peut être réutilisée lorsque vous démarrez une autre instance de la même application Java. La JVM peut réutiliser les données précalculées de l'archive, ce qui réduit le temps de démarrage.

Les considérations suivantes s'appliquent à l'utilisation d'AppCDS :

  • L'archive AppCDS à réutiliser doit être reproduite par exactement les mêmes distribution, version et architecture OpenJDK que celles initialement utilisées pour la produire.
  • Vous devez exécuter votre application au moins une fois pour générer la liste des classes à partager, puis générer l'archive AppCDS à l'aide de cette liste.
  • La couverture des classes dépend du chemin d'accès au code utilisé lors de l'exécution de l'application. Pour augmenter la couverture, déclenchez plus de chemins d'accès au code par programmation.
  • L'application doit se fermer correctement pour générer cette liste de classes. Envisagez de mettre en œuvre une option d'application servant à indiquer la génération de l'archive AppCDS, de sorte qu'elle puisse se fermer immédiatement.
  • L'archive AppCDS ne peut être réutilisée que si vous lancez de nouvelles instances exactement de la même manière que l'archive.
  • L'archive AppCDS ne fonctionne qu'avec un package de fichiers JAR standard. Vous ne pouvez pas utiliser de fichiers JAR imbriqués.

Exemple Spring Boot avec un fichier JAR ombré

Par défaut, les applications Spring Boot utilisent un fichier uber JAR imbriqué, qui ne fonctionne pas pour AppCDS. Ainsi, si vous utilisez AppCDS, vous devez créer un fichier JAR ombré. Par exemple, avec Maven et le plug-in Maven Shade :

<build>
  <finalName>helloworld</finalName>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-shade-plugin</artifactId>
      <configuration>
        <keepDependenciesWithProvidedScope>true</keepDependenciesWithProvidedScope>
        <createDependencyReducedPom>true</createDependencyReducedPom>
        <filters>
          <filter>
            <artifact>*:*</artifact>
            <excludes>
              <exclude>META-INF/*.SF</exclude>
              <exclude>META-INF/*.DSA</exclude>
              <exclude>META-INF/*.RSA</exclude>
            </excludes>
          </filter>
        </filters>
      </configuration>
      <executions>
        <execution>
          <phase>package</phase>
          <goals><goal>shade</goal></goals>
          <configuration>
            <transformers>
              <transformer implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
                <resource>META-INF/spring.handlers</resource>
              </transformer>
              <transformer implementation="org.springframework.boot.maven.PropertiesMergingResourceTransformer">
                <resource>META-INF/spring.factories</resource>
              </transformer>
              <transformer implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
                <resource>META-INF/spring.schemas</resource>
              </transformer>
              <transformer implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer" />
              <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                <mainClass>${mainClass}</mainClass>
              </transformer>
            </transformers>
          </configuration>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

Si votre fichier JAR ombré contient toutes les dépendances, vous pouvez produire une archive simple pendant la création du conteneur à l'aide d'un Dockerfile :

# Use Docker's multi-stage build
FROM adoptopenjdk:11-jre-hotspot as APPCDS

COPY target/helloworld.jar /helloworld.jar

# Run the application, but with a custom trigger that exits immediately.
# In this particular example, the application looks for the '--appcds' flag.
# You can implement a similar flag in your own application.
RUN java -XX:DumpLoadedClassList=classes.lst -jar helloworld.jar --appcds=true

# From the captured list of classes (based on execution coverage),
# generate the AppCDS archive file.
RUN java -Xshare:dump -XX:SharedClassListFile=classes.lst -XX:SharedArchiveFile=appcds.jsa --class-path helloworld.jar

FROM adoptopenjdk:11-jre-hotspot

# Copy both the JAR file and the AppCDS archive file to the runtime container.
COPY --from=APPCDS /helloworld.jar /helloworld.jar
COPY --from=APPCDS /appcds.jsa /appcds.jsa

# Enable Application Class-Data sharing
ENTRYPOINT java -Xshare:on -XX:SharedArchiveFile=appcds.jsa -jar helloworld.jar

Désactiver la validation des classes

Lorsque la JVM charge en mémoire des classes pour exécution, elle vérifie que chaque classe ne présente aucune altération, modification malveillante ou élément corrompu. Si votre pipeline de livraison de logiciels est approuvé (par exemple, vous pouvez vérifier et valider chaque sortie), si vous pouvez faire entièrement confiance au bytecode de votre image de conteneur et que votre application ne charge aucune classe issue de sources distantes arbitraires, vous pouvez désactiver cette validation. La désactivation de cette validation peut améliorer la vitesse de démarrage en cas de chargement d'un grand nombre de classes au lancement.

Pour un service de diffusion Knative, configurez la variable d'environnement suivante :

JAVA_TOOL_OPTIONS="-noverify"

Réduire la taille de la pile de threads

La plupart des applications Web Java sont construites sur le modèle "un thread par connexion". Chaque thread Java consomme de la mémoire native (et non du tas de mémoire). C'est ce que l'on appelle la pile de threads, qui utilise par défaut 1 Mo par thread. Si votre application gère 80 requêtes simultanées, cela représente au moins 80 threads, c'est-à-dire 80 Mo d'espace utilisé pour la pile de threads. Cette mémoire s'ajoute à la taille du tas de mémoire. La valeur par défaut peut s'avérer plus grande que nécessaire. Vous pouvez réduire la taille de la pile de threads.

Si vous la réduisez trop, vous risquez d'être confronté à une erreur java.lang.StackOverflowError. Vous pouvez profiler votre application et déterminer la taille optimale à configurer pour la pile de threads.

Pour un service Knative serving, configurez la variable d'environnement:

JAVA_TOOL_OPTIONS="-Xss256k"

Réduire les threads

Vous pouvez optimiser la mémoire en réduisant le nombre de threads, en faisant appel à des stratégies réactives non bloquantes et en évitant les activités d'arrière-plan.

Réduire le nombre de threads

Chaque thread Java est susceptible d'augmenter l'utilisation de la mémoire en raison de la pile de threads. Knative serving autorise un maximum de 80 requêtes simultanées. Avec le modèle "un thread par connexion", vous avez donc besoin d'un maximum de 80 threads pour gérer toutes les requêtes simultanées. La plupart des serveurs et des frameworks Web vous permettent de configurer le nombre maximal de threads et de connexions. Par exemple, dans Spring Boot, vous pouvez limiter le nombre maximal de connexions dans le fichier applications.properties :

server.tomcat.max-threads=80

Écrire du code réactif non bloquant pour optimiser la mémoire et le démarrage

Pour réellement réduire le nombre de threads, envisagez d'adopter un modèle de programmation réactif non bloquant, qui diminue considérablement le nombre de threads tout en gérant davantage de requêtes simultanées. Les frameworks d'application tels que Spring Boot avec Webflux, Micronaut et Quarkus sont compatibles avec les applications Web réactives.

Les frameworks réactifs tels que Spring Boot avec Webflux, Micronaut et Quarkus présentent généralement des temps de démarrage plus rapides.

Si vous continuez à écrire du code bloquant dans un framework non bloquant, le débit et les taux d'erreur en seront fortement affectés dans un service Knative serving. En effet, les frameworks non bloquants ne présentent qu'un petit nombre de threads, par exemple deux ou quatre. Si votre code est bloquant, il ne peut traiter que très peu de requêtes simultanées.

Ces frameworks non bloquants peuvent également décharger le code bloquant dans un pool de threads illimité. Ainsi, même s'il peut accepter de nombreuses requêtes simultanées, le code bloquant s'exécute dans de nouveaux threads. Si les threads s'accumulent de manière illimitée, vous épuisez la ressource de processeur et aboutissez à une situation de thrashing. La latence en sera sévèrement affectée. Si vous utilisez un framework non bloquant, assurez-vous de comprendre les modèles de pool de threads et de leur appliquer des limitations en conséquence.

Éviter les activités d'arrière-plan

Knative serving limite le processeur d'une instance lorsque celle-ci ne reçoit plus de requêtes. Les charges de travail traditionnelles ayant des tâches en arrière-plan nécessitent une attention particulière lors de l'exécution dans Knative serving.

Par exemple, si vous collectez des métriques d'application et que vous regroupez ces métriques en arrière-plan pour les envoyer à intervalles réguliers, celles-ci ne seront pas envoyées si le processeur est soumis à une limitation. Si votre application reçoit continuellement des requêtes, vous devriez rencontrer moins de problèmes. Si votre application présente un faible nombre de requêtes par seconde, il est possible que la tâche en arrière-plan ne s'exécute jamais.

Voici un certain nombre de structures bien connues qui s'exécutent en arrière-plan et nécessitent une attention particulière de votre part :

  • Pools de connexions JDBC : les nettoyages et les vérifications de connexion ont généralement lieu en arrière-plan.
  • Émetteurs de traces distribuées : les traces distribuées sont généralement regroupées et envoyées en arrière-plan, soit de façon périodique, soit lorsque la mémoire tampon est saturée.
  • Émetteurs de métriques : les métriques sont généralement regroupées et envoyées à intervalles réguliers en arrière-plan.
  • Avec Spring Boot, toutes les méthodes comportant l'annotation @Async.
  • Minuteurs : tout déclencheur basé sur un minuteur (par exemple, ScheduledThreadPoolExecutor, Quartz, ou une annotation Spring @Scheduled) est susceptible de ne pas s'exécuter lorsque les processeurs sont limités.
  • Récepteurs de messages : par exemple, les clients pull de flux Pub/Sub, les clients JMS ou les clients Kafka s'exécutent généralement dans des threads en arrière-plan sans nécessiter de requêtes. Ceux-ci ne fonctionnent pas lorsque votre application ne reçoit aucune requête. La réception de messages par ce biais n'est pas recommandée dans Knative serving.

Optimiser les applications

Dans le code de votre service Knative serving, vous pouvez également optimiser le temps de démarrage et l'utilisation de la mémoire.

Limiter les tâches de démarrage

Les applications Web Java traditionnelles peuvent avoir de nombreuses tâches à exécuter au démarrage (préchargement des données, préchauffage du cache, établissement de pools de connexions, etc.). Lorsqu'elles sont exécutées de manière séquentielle, ces tâches peuvent se révéler lentes. Toutefois, si vous souhaitez qu'elles s'exécutent en parallèle, vous devez augmenter le nombre de cœurs de processeur.

Actuellement, Knative serving envoie une vraie requête utilisateur pour déclencher le démarrage à froid d'une instance. Les utilisateurs dont la requête est attribuée à une instance tout juste démarrée peuvent être confrontés à des délais importants. À l'heure actuelle, Knative serving ne dispose pas d'une "vérification d'aptitude" qui permettrait d'éviter l'envoi de requêtes à des applications qui ne sont pas prêtes.

Utiliser le pooling de connexions

Si vous utilisez des pools de connexions, sachez que ceux-ci peuvent supprimer les connexions inutiles en arrière-plan (consultez la section Éviter les activités d'arrière-plan). Si votre application présente un faible nombre de requêtes par seconde et peut tolérer une latence élevée, envisagez d'ouvrir et de fermer les connexions pour chaque requête. Si votre application présente un nombre élevé de requêtes par seconde, les suppressions en arrière-plan peuvent se poursuivre tant qu'il existe des requêtes actives.

Dans les deux cas, le goulot d'étranglement se situe au niveau de l'accès à la base de données de l'application, qui est limité par le nombre maximal de connexions autorisées par la base de données. Calculez le nombre maximal de connexions que vous pouvez établir par instance Knative serving et configurez le nombre maximal d'instances Knative serving de sorte que le nombre maximal d'instances multiplié par le nombre de connexions par instance soit inférieur au maximum de connexions autorisées.

Utiliser Spring Boot

Si vous utilisez Spring Boot, vous pouvez envisager les optimisations suivantes.

Utiliser Spring Boot version 2.2 ou ultérieure

À partir de sa version 2.2, Spring Boot a été fortement optimisé pour gagner en vitesse de démarrage. Si vous utilisez des versions de Spring Boot antérieures à la version 2.2, envisagez d'effectuer la mise à niveau ou d'appliquer manuellement des optimisations individuelles.

Utiliser l'initialisation différée

Il existe dans Spring Boot en version 2.2 et ultérieure une option globale d'initialisation différée que vous pouvez activer. Celle-ci permet d'améliorer la vitesse de démarrage, à un coût : la latence de la première requête peut être supérieure, car il est nécessaire d'attendre la première initialisation des composants.

Vous pouvez activer l'initialisation différée dans application.properties :

spring.main.lazy-initialization=true

Vous pouvez également utiliser une variable d'environnement :

SPRING_MAIN_LAZY_INITIALIZATIION=true

Cependant, si vous utilisez des instances de type min, l'initialisation différée n'aura aucune utilité, car l'initialisation doit avoir lieu au démarrage de l'instance min.

Éviter l'analyse des classes

L'analyse des classes entraîne un surcroît de lectures de disque dans Knative serving, car, dans Knative serving, l'accès au disque est généralement plus lent qu'avec une machine normale. Assurez-vous que l'analyse des composants soit limitée ou même totalement évitée. Pensez à utiliser Spring Context Indexer pour prégénérer un index. L'amélioration effective que cela représente sur la vitesse de démarrage dépend de votre application.

Par exemple, dans votre fichier Maven pom.xml, ajoutez la dépendance d'indexation suivante (il s'agit en fait d'un processeur d'annotations) :

<dependency>
  <groupId>org.springframework</groupId>
  <artifactId>spring-context-indexer</artifactId>
  <optional>true</optional>
</dependency>

Utiliser les outils de développement Spring Boot sans les transférer en production

Si vous utilisez les outils pour les développeurs Spring Boot pendant le développement, assurez-vous que ceux-ci ne sont pas empaquetés dans l'image du conteneur de production. Cela peut se produire si vous avez compilé l'application Spring Boot sans les plug-ins de compilation Spring Boot (par exemple, en utilisant le plug-in Shade ou Jib pour effectuer la mise en conteneur).

Dans ce cas, assurez-vous que l'outil de compilation exclut explicitement les outils de développement Spring Boot. Vous pouvez aussi désactiver explicitement les outils de développement Spring Boot.

Étape suivante

Pour accéder à d'autres conseils, consultez les pages suivantes :