Ca ne vas en tout cas pas améliorer les perfs...
Passer toutes les requêtes http du C au Java n'a
jamais améiloré des perfs... Sans compter que le
projet mod_jk n'est pas le plus documenté et pas non plus exempts de bugs...
Par contre cela peut-être utile:
- pour des raisons de sécurité d'avoir un serveur Web apache en frontal
- pour des raisons d'url rewriting
(simplification des urls Jahia, gestion d'alias, etc...)
- pour des raisons de mod (mod_php, mod_perl,etc)
/SC
At 14:45 09.03.2006, you wrote:
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.
>
>
>
- -- --- -----=[ scroisier at jahia dot com ]=---- --- -- -
CEO - Jahia Ltd, 45 rue de la gare, 1260 Nyon (Switzerland)
Jahia : The Java Unified Web Platform
www.jahia.org - The community and product web site
www.jahia.com - The commercial services company
www.collaborativesource.org - The Collaborative Source Initiative
