Merci pour toutes ces précisions. Je voulais vous demander également si le fait d'utiliser tomcat avec apache (je pense au mod_jk ou bien mod_proxy) pouvait augmenter les performances ou c'est vraiment utile que si on souhaite plusieurs techno sur le même port ?
Selon Stéphane Croisier <[EMAIL PROTECTED]>: > > 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. > > >
