Si vous avez une forte charge, je vous suggère fortement de rajouter des fragments de cache (style OSCache HTML taglibs : http://www.opensymphony.com/oscache/wiki/JSP%20Tags.html) et ceci tout particulièrement sur les menus (genre left menu) ou autres boxes dynamiques/filtres complexes, etc... Le tout uniquement en live mode. Ceci peut par exemple être très utile en terme de performance pour toutes les pages qui ne sont pas cachées par le cache HTML de Jahia genre /bypass ou autre /cache/offonce et évitera de devoir "reconstruire" tous les menus, à chaque hit, depuis la base. De même pour des filtres complexes (genre récupérer tous les containers News triés par catégorie et par user + par date), vous pouvez également tenter de cacher toutes les combinaisons de filtres dans un fragment OSCache.
A vous ensuite de déterminer le temps d'expiration de ces entrées de caches HTML (par exemple 5 ou 10 minutes). Le seul risque est ensuite d'avoir une légère inconsistence et/ou qq erreurs 404 pendant ces 5 ou 10 minutes. Ainsi si vous supprimez une page dans un menu et que ce menu est caché dans un fragment OSCache en mode live, la page restera encore "visible" jusque à ce que le fragment soit expiré et regénéré.
Vous pouvez bien entendu gérer une clé de cache global (la même pour tous les utilisateurs) ou par utilisateur (chaque utilisateur a sa propre entrée de cache). Bref ensuite "the sky the limit"...
Il existe un exemple dans les Coporate Template (box de type "Last 5 news" qui permet de récupérer tous els objes de type News et de les filtrer + qui cache toutes les combinaisons de filtres au fur et à mesure).
En gros tous les filtres, applications et/ou Absolute (donc menus) sont très consommateurs en temps CPU. Donc si vous pouvez vous satisfaire d'un léger délai de syncronisation en mode live (en mode edit ce n'est souvent pas raisonnable car l'éditeur ne voit alors plus le contenu qu'il vient de rajouter), c'est une solution idéale en terme de performance et évitera multitudes de requêtes sur le serveur Jahia + DB.
Ceci c'est un "workaround" pour Jahia 4.x. Dans Jahia 5.0, nous pourrons coupler Jahia à un serveur de Cache Proxy indépendant compatible avec la norme ESI (www.esi.org). Le méchanisme reste le même excepté que Jahia se chargera tout seul de flusher les fragments de cache en mode live ou en edit en détectant automatiquement (via un frameowkr AOP) les actions réalisés (update, workflow, etc...) + disposera de nombreuses options pour grouper les fragments de cache par utilisateur, par groupe, etc...
Stéphane At 11:33 08.03.2006, you wrote:
Bonjour, Je cherche à optimiser les performances de jahia. Existe-t-il un autre document disponible que le "fine tuning tips" ? Avez-vous des conseils à me donner ? Merci. Cordialement.
