Optimisation des performances d'un serveur Liferay:
quelques pratiques issues de retour d'expérience.

Publié le 16 juillet 2012

Par B. Jc. BAKENEGHE et Xavier FANON

(Koossery Technology)

Nous présentons ici un retour d'expérience sur quelques bonnes pratiques de configurations pour optimiser les performances d'un serveur Liferay.
Nous présenterons les optimisations au niveau système puis au niveau du web-tiers.

Version PDF Version hors-ligne Version eBooks

I. Optimisation des configurations systèmes
I-1. JVM
I-1-1. La mémoire de la pile
I-1-2. Le garbage collector
II. Optimisation des configurations au niveau du web-tiers
II-1. Les filtres
II-2. javascripts
II-3. Thèmes, CSS, Look and Feel
II-4. Template Velocity
II-5. Index lucene

I. Optimisation des configurations systèmes

I-1. JVM

I-1-1. La mémoire de la pile

Un swap disque élevé ou un garbage collector qui intervient trop souvent impactent négativement les performances du serveur Liferay. Il faut donc configurer de façon optimale la mémoire.
La configuration de la mémoire se fait au travers des paramètres de la JVM.
Au fur et à mesure que les objets sont créés, ils sont stockés dans une pile qu'on peut configurer au travers des paramètres suivants :

Xms : indique la quantité initiale de mémoire pour la pile.
Xmx : indique la quantité maximale de mémoire pour la pile. Lorsque la taille Xmx est atteinte, la JVM va générer une exception 'java.lang.OutOfMemoryError: Java heap space'.

Pour un serveur Liferay, il est conseillé de configurer une taille fixe pour la pile et donc d'avoir les mêmes valeurs pour Xms et Xmx.
Il existe un dernier paramètre qui indique la quantité de mémoire qu'on souhaite allouer pour le chargement des classes. Il s'agit du paramètre PermGen. On le configure au travers de :

XX:MaxPermSize : si la mémoire du permgen est insuffisante une 'java.lang.OutOfMemoryError: PermGen space' sera renvoyée.

Si on part de l'hypothèse qu'on a un serveur (2 core cpu avec 2Go de RAM) dédié pour Liferay, la configuration ci-dessous est mieux adaptée pour le serveur Liferay :

-Xms2048m -Xmx2048m -XX:MaxPermSize=256m

Dans les systèmes 64bits, il est possible pour notre serveur Liferay de disposer de largement plus de 2 Go de mémoire.
Dans ce cas, il peut être tentant de configurer Xms et Xmx avec une valeur supérieure à 2048m. Une telle configuration serait pénalisante car une valeur trop grande pour notre pile ferait que le garbage collector mettrait beaucoup plus de temps pour le nettoyage de la pile. Lorsqu'on est dans cette situation, il est préférable de mettre en place de multiples JVM avec chacune une instance Liferay.

I-1-2. Le garbage collector

Le rôle du garbage collector est d'aller nettoyer la pile en la vidant de tous les objets qui ne sont plus référencés.
Lors du passage du garbage collector, tous les processus en cours dans la pile sont stoppés jusqu'à ce que le nettoyage soit terminé. Il en résulte donc un ralentissement du système à chaque passage du garbage collector.
Afin de limiter l'impact du passage du garbage collector, on peut finement configurer certains paramètres de la JVM :

-XX: +UseParNewGC : le garbage collector déroule plusieurs phases lors de son exécution. Au cas où ces phases s'exécutent de façon sérialisée, cela est fortement pénalisant pour un serveur Liferay car alors on observera de fréquents ralentissements du système. Avec un serveur multi CPU, on a la possibilité de configurer l'exécution des phases.
-XX:ParallelGCThreads : nombre de thread à lancer pour le garbage collector. Traditionnellement on positionne cela au nombre de CPU du serveur Liferay.
-XX:+UseConcMarkSweepGC : cette configuration indique au garbage collector de ne pas complètement stopper le fonctionnement des processus en cours dans la pile. Pour cela il marque les objets accessibles par l'application ce qui permet à cette dernière de continuer à fonctionner. Il repasse ensuite pour répertorier les objets modifiés pendant le fonctionnement de l'application. Il fait enfin un balayage consistant à nettoyer les objets non utilisés (de-référencés).
-XX:NewSize -XX:MaxNewSize : les paramètres NewSize et MaxNewSize indique la taille de la zone de la pile réservé aux objets marqués 'jeune'. Le garbage collector intervient le plus souvent dans cette zone. Pour un serveur Liferay, il est conseillé de positionner NewSize et MaxNewSize au tiers de la capacité de la pile.
-XX :SurvivorRatio : dans la pile on distingue les objets à longue durée de vie (objets anciens) et les objets récents. Parmi les objets récents, on distingue les nouveaux objets qui viennent d'être chargés (eden) et les nouveaux objets qui ont survécus à une opération de nettoyage (objets survivor) et donc qui vont être promu objets anciens. Le SurvivorRatio est le ratio entre les objets la section eden et la section survivor. Dans un serveur Liferay, on crée beaucoup d'objets mais on en conserve peu. Il est donc conseillé d'avoir un SurvivorRatio grand.

Si on part de l'hypothèse qu'on a un serveur (2 core cpu avec 2Go de RAM) dédié pour Liferay, la configuration ci-dessous est mieux adaptée pour le serveur Liferay :

JAVA_OPTS="$JAVA_OPTS -XX:NewSize=700m -XX:MaxNewSize=700m -Xms2048m -Xmx2048m -XX:MaxPermSize=256m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:SurvivorRatio=20 -XX:ParallelGCThreads=2"

II. Optimisation des configurations au niveau du web-tiers

Pour un portail Liferay à fort trafic, il peut être précieux d'activer certains filtres, notamment ceux en rapport avec le cache au niveau web-tiers.
Il faut activer les filtres suivants :

'com.liferay.portal.servlet.filters.strip.StripFilter=true' afin de supprimer les 'zones' blanches dans le rendu web.
'com.liferay.portal.servlet.filters.header.HeaderFilter' pour ce qui concerne le http header caching.
'com.liferay.portal.servlet.filters.cache.CacheFilter'=true pour activer le cache du contenu web au niveau de EHCache.
'com.liferay.portal.servlet.filters.gzip.GZipFilter'=true pour compresser (gzip) les réponses à destination des users qui ont la possibilité de les dé zipper.
'com.liferay.portal.servlet.filters.compression.CompressionFilter'=true.
'com.liferay.portal.servlet.filters.minifier.MinifierFilter' pour 'minifier' les css et javascripts.
'com.liferay.portal.servlet.filters.layoutcache.LayoutCacheFilter'=true pour mettre les pages dans le cache afin d'accélérer le rendu.
'com.liferay.portal.servlet.filters.layoutcache.LayoutCacheFilter.refresh.time' : durée de vie en millisecondes du cache (0 si le cache ne doit jamais expirer).

Il faut désactiver les filtres suivants car ils ralentissent les performances du serveur Liferay :

'com.liferay.portal.servlet.filters.audit.AuditFilter'=false : pour chaque requête ce filtre renseigne l'objet AuditRequestThreadLocal avec des éléments qui serviront plutard pour l'audit.
'com.liferay.portal.servlet.filters.monitoring.MonitoringFilter'=false : ce filtre sert à collecter les informations dans le but de monitorer les performances.
'com.liferay.portal.servlet.filters.sso.ntlm.NtlmFilter'=false si on a pas mis en place une authentification NTLM.

Plus généralement, il faut désactiver les filtres suivants s'ils ne sont pas mis en oeuvre dans le serveur Liferay :

'com.liferay.portal.servlet.filters.autologin.AutoLoginFilter'.
'com.liferay.portal.servlet.filters.doubleclick.DoubleClickFilter'.
'com.liferay.portal.sharepoint.SharepointFilter'.

II-1. Les filtres

II-2. javascripts

'javascript.barebone.enabled'=true : cette propriété indique qu'il faut d'abord étudier l'éventualité de ne charger que la liste minimale des fichiers javascript (cette liste est indiquée dans la propriété 'javascript.barebone.files' ) et si insuffisante, alors ça n'est dans ce cas qu'il faut charger l'ensemble des fichiers spécifiés dans la propriété 'javascript.everything.files'.
'javascript.fast.load'=true : pour charger de façon compacte d'un seul coup les fichiers listés dans 'javascript.barebone.files' et ceux listés dans 'javascript.everything.files'.
'javascript.log.enabled'=false : pour désactiver les log javascript.

II-3. Thèmes, CSS, Look and Feel

Afin d'éviter les modifications à chaud des css sur les portlet, il faut positionner : 'portlet.css.enabled'=false.
Afin d'éviter une vérification systématique de la date de dernière modification des css ou des javascripts, il faut 'positionner last.modified.check'=false.
Afin d'éviter les modifications à chaud du look and feel, il faut positionner : 'look.and.feel.modifiable'=false.
Pour ce qui concerne les theme, appliquer les configurations suivantes 'theme.css.fast.load'=true et 'theme.images.fast.load'=true.

II-4. Template Velocity

Afin d'effectuer un cache des template Velocity, il faut mettre la configuration suivante :
'velocity.engine.resource.manager.cache.enabled'=true.

II-5. Index lucene

Afin d'éviter un indexage à chaque redémarrage du serveur, il faut positionner :
'index.on.startup'=false.

Tous nos remerciements au comité de rélecture de developpez.com

Koossery Technology
Java EE- .NET- Alfresco- Liferay