bookmark-service<\/code> de mon Dojo Quarkus bookmarkit<\/a> d\u00e9marre en 1,2s sur mon laptop.<\/p>\n![\"\"](\"https:\/\/i0.wp.com\/loicmathieu.fr\/wordpress\/wp-content\/uploads\/quarkus_metrics_graphic_bootmem_wide.png?resize=640%2C296&ssl=1\")
\nUn autre point non mentionn\u00e9, est la taille de l’image Docker. Une application native ne contiendra que le code utilis\u00e9 par l’application (gr\u00e2ce au dead code \u00e9limination de GraalVM), ainsi qu’une JVM minimaliste (SubstrateVM), et sera donc plus petite qu’une image standard qui embarque l’int\u00e9gralit\u00e9 des librairies tierces ainsi qu’une JVM compl\u00e8te.<\/p>\n
Mais, d\u00e9ployer son application Quarkus comme une application native a quelques inconv\u00e9nients :<\/p>\n
- A cause du close world assumption<\/em> de GraalVM, il faut que toutes les librairies utilis\u00e9es soient compatibles GraalVM. Ceci est garantie pour les extensions Quarkus, mais pour les autres, c’est \u00e0 vous de v\u00e9rifier, et il peut parfois y avoir de mauvaises surprises.<\/li>\n\n
- SubstrateVM est une JVM partielle, elle ne supporte ni JMX ni JVM-TI (et donc pas d’agents Java), ce qui peut grandement complexifier le monitoring et l’administration de votre application.<\/li>\n\n
- Une application native a des performances en pointe qui sont inf\u00e9rieures \u00e0 une application d\u00e9ploy\u00e9e dans la JVM. Principalement parce que le Just-In-Time Compiler (le JIT) de Java va profiler votre application lors de son utilisation et pourra donc effectuer des optimisations plus pertinentes que GraalVM qui r\u00e9alise ces optimisations \u00e0 la compilation (compilateur Ahead-Of-Time – AOT).<\/li>\n<\/ul>\n
Si vous voulez d\u00e9ployer votre application Quarkus dans une JVM standard, mais optimiser son temps de d\u00e9marrage et la taille de l’image Docker, alors Jlink<\/strong> et AppCDS<\/strong> peuvent vous aider !<\/p>\nDans les paragraphes suivants, je vais utiliser l’application bookmark-service<\/a> comme exemple. Une JVM 11 minimum est n\u00e9cessaire (j’ai utilis\u00e9 OpenJDK 11.0.5).<\/p>\nJlink<\/h2>\n
Jlink<\/strong> permet de g\u00e9n\u00e9rer une JVM customis\u00e9e qui ne contiendra que les modules n\u00e9cessaires au fonctionnement de votre application. Ceci est rendu possible gr\u00e2ce \u00e0 la modularisation du JDK qui a \u00e9t\u00e9 faite pour Java 9 (JSR-376<\/a> – projet Jigsaw). Qui dit taille r\u00e9duite de JVM, dit image Docker plus petite !<\/p>\nJlink<\/strong> prend en entr\u00e9e la liste des modules \u00e0 inclure dans votre JVM customis\u00e9e. Pour connaitre cette liste, il faut utiliser l’outil jdeps<\/strong>.<\/p>\nTout d’abord, il faut configurer Quarkus pour g\u00e9n\u00e9rer un fat jar (ou uber jar) pour que jdeps<\/strong> puisse analyser tout le code de votre application. Pour ce faire, il faut ajouter la propri\u00e9t\u00e9 suivante dans votre application.properties<\/code> :<\/p>\nquarkus.package.uber-jar=true<\/code><\/pre>\nOn package ensuite l’application via mvn clean package<\/code>.<\/p>\nPuis on lance la commande jdeps<\/strong> avec l’option --list-deps<\/code> qui permet de lister les modules dont votre application d\u00e9pend.<\/p>\nVoici le r\u00e9sultat de la commande jdeps<\/strong> avec le uber jar de l’application bookmark-service<\/code> :<\/p>\n$ jdeps --list-deps target\/bookmark-service-1.0-SNAPSHOT-runner.jar \n JDK removed internal API\/org.relaxng.datatype\n java.base\/sun.security.util\n java.base\/sun.security.x509\n java.compiler\n java.datatransfer\n java.desktop\n java.instrument\n java.logging\n java.management\n java.naming\n java.rmi\n java.security.jgss\n java.security.sasl\n java.sql\n java.transaction.xa\n java.xml\n jdk.jconsole\n jdk.management\n jdk.unsupported\n<\/code><\/pre>\nPour cr\u00e9er une JVM customis\u00e9e, il faut utiliser jlink<\/strong> en lui donnant la liste des modules r\u00e9sultants de l’appel \u00e0 la commande jdeps<\/strong> via l’option -add-modules<\/code>. Petite subtilit\u00e9, les deux modules java.base\/sun.security.util<\/code> et java.base\/sun.security.x509<\/code> ne doivent pas \u00eatre int\u00e9gr\u00e9es, mais on doit int\u00e9grer le module java.base<\/code> \u00e0 la place. Je ne sais pas d’o\u00f9 vient cette incoh\u00e9rence de r\u00e9sultat de la commande jdeps<\/strong>, mais le module java.base<\/code> est utilis\u00e9 par toute application Java, donc il doit syst\u00e9matiquement \u00eatre pr\u00e9sent.<\/p>\nPour l’application bookmark-service<\/code>, voici la commande jlink<\/strong> que j’ai utilis\u00e9 :<\/p>\n$ jlink --no-header-files --no-man-pages --output target\/customjdk --compress=2 --strip-debug\n--module-path $JAVA_HOME\/jmods --add-modules java.base,java.base,java.base,java.compiler,\njava.datatransfer,java.desktop,java.instrument,java.logging,java.management,java.naming,\njava.rmi,java.security.jgss,java.security.sasl,java.sql,java.transaction.xa,\njava.xml,jdk.jconsole,jdk.management,jdk.unsupported\n<\/code><\/pre>\nComme je voulais avoir une JVM la plus petite possible, j’ai ajout\u00e9 les options suivantes \u00e0 la commande jlink<\/strong> :<\/p>\n--no-header-files<\/code> : Ne pas inclure les fichiers header,<\/li>\n\n--no-man-pages<\/code> : Ne pas inclure les pages de manuel,<\/li>\n\n--compress=2<\/code> : Compression de niveau ZIP pour les fichiers compressibles,<\/li>\n\n--strip-debug<\/code> : Ne pas inclure les informations de debug.<\/li>\n<\/ul>\nApr\u00e8s cela, on peut utiliser la JVM g\u00e9n\u00e9r\u00e9e dans le r\u00e9pertoire target\/customjdk<\/code> pour lancer notre application :<\/p>\n$ target\/customjdk\/bin\/java -Xmx32m -jar target\/bookmark-service-1.0-SNAPSHOT-runner.jar\n<\/code><\/pre>\nSi on compare le d\u00e9marrage de notre application avec notre JVM customis\u00e9e et la JVM standard, il n’y a pas d’avantage au RSS ni au temps de d\u00e9marrage. Le seul int\u00e9r\u00eat est la taille de la JVM qui est pass\u00e9e de 314Mo \u00e0 51Mo !<\/p>\n
Id\u00e9alement, il faudrait automatiser \u00e7a dans votre build Docker via un Dockerfile multi-stage …<\/p>\n
Pour aller plus loin sur jlink,<\/strong> je vous invite \u00e0 consulter cet article : Using jlink to build java runtimes for non modular applications<\/a>.<\/p>\nAppCDS – Application Class Data Sharing<\/h2>\n
Attention : si vous voulez utiliser AppCDS<\/strong> avec jlink<\/strong>, il faudra utiliser la JVM customis\u00e9e dans les commandes de ce paragraphe au lieu de votre JVM par d\u00e9faut.<\/p>\nUne des raisons du temps de d\u00e9marrage cons\u00e9quent d’une application Java, est que, pour chaque classe, la JVM doit la charger depuis le disque, la v\u00e9rifier, puis cr\u00e9er une structure de donn\u00e9es sp\u00e9cifique (class metadata).<\/p>\n
Application Class Data Sharing (AppCDS) est une fonctionnalit\u00e9 via laquelle on peut cr\u00e9er une archive des metadatas de nos classes, pour \u00e9viter de le faire au d\u00e9marrage. Une fois ces metadatas charg\u00e9s, il n’y a aucune diff\u00e9rence de comportement avec une application n’utilisant pas AppCDS.<\/p>\n
L’utilisation d’AppCDS<\/strong> se fait en trois \u00e9tapes :<\/p>\nEtape 1<\/strong> : Cr\u00e9ation de la liste de classes \u00e0 archiver.<\/p>\njava -XX:DumpLoadedClassList=target\/classes.lst -jar target\/bookmark-service-1.0-SNAPSHOT-runner.jar\n<\/code><\/pre>\nJ’ai arr\u00eat\u00e9 l’application juste apr\u00e8s son lancement, mais on peut imaginer l’utiliser un peu plus longtemps (lancement de test fonctionnel par exemple) pour s’assurer que tout le code de l’application ait bien \u00e9t\u00e9 appel\u00e9, et donc que le plus de classes possible seront list\u00e9es.<\/p>\n
Etape 2<\/strong> : G\u00e9n\u00e9ration de l’archive en utilisant l’option JVM -Xshare:dump<\/code> qui demande \u00e0 AppCDS<\/strong> de la cr\u00e9er.<\/p>\njava -Xshare:dump -XX:SharedClassListFile=target\/classes.lst -XX:SharedArchiveFile=target\/app-cds.jsa --class-path target\/bookmark-service-1.0-SNAPSHOT-runner.jar\n<\/code><\/pre>\nCette commande ne lance pas l’application. Elle va seulement g\u00e9n\u00e9rer un fichier app-cds.jsa<\/code> de 69Mo qu’on pourra ensuite utiliser pour lancer notre application.<\/p>\nEtape 3<\/strong> : On lance l’application en lui passant l’archive cr\u00e9\u00e9e.<\/p>\njava -XX:SharedArchiveFile=target\/app-cds.jsa -jar target\/bookmark-service-1.0-SNAPSHOT-runner.jar\n<\/code><\/pre>\nAvec une archive, l’application se lance en 500ms au lieu de 1,2s, ce qui fait -60% de temps de d\u00e9marrage<\/strong> !<\/p>\nOn n’a h\u00e9las, pas de diff\u00e9rence au niveau empreinte m\u00e9moire.<\/p>\n