At 17:06 26.06.2006, you wrote:
At 10:49 2006-06-26, you wrote:
outch !
mon soucis est que précédement (et avec un
serveur moins puissant) nous n'avions pas cette lenteur...
en "diffant" l'ancienne base et la nouvelle, je
me rends compte que plusieurs index manquent : c'est ma nouvelle piste ;)
mais peut etre avons nous moins d'édition que
vous ? quelle est votre fréquentation moyenne.
Pour moi, j'ai ~ 8000 visiteurs uniques (meme
IP / 1 heure) ~ 40000 pages vues partagées
avec une ~20e d'éditeurs simultanés.
Pour les stats d'utilisation je pourrais pas
dire, mais nous avons 35 éditeurs. Toutefois, il
arrive rarement qu'ils travaillent tous en même temps.
Les index c'est crucial en effet, quand on a
ajouté les index suggérés dans la doc de Jahia
(au début début) on a noté une amélioration des
performances. Avec MS SQL il a suffit d'un
copier-coller des requêtes de création dans SQL
query analyser et de les exécuter. MS SQL est
aussi configuré pour se créer des index au
besoin, si l'utilisation d'une ressource non indexée devient intensive.
En effet les indexes sont cruciaux. Sinon les
caches au niveau de la DB peuvent également bcp
aider. MySQL possède ainsi un cache proxy interne
que l'on peut paramétrer (je ne connais pas assez
les autres bases) mais ce genre de caches peut-là
également booster les performances puisqu'il va
permettre de renvoyer de la base à Jahia toutes
les requêtes que Jahia n'est pas en mesure de
cacher et regénère très régulièrement (en gros
principalement les absolute containers que nous
ne sommes pas en mesure de cacher au niveau de
Jahia - donc tous les menus - et qui sont donc
les sources princiaples des requêtes et des délais de performances).
Dans Jahia 5.0 la situation a un peu changé
puisque c'est hibernate qui gère directement tous
ces indexes + caches bas niveau.
J'ai ete plus trash que vous ;)
comme la limite sur des processeurs 64bits
n'est plus pour java, j'ai carrément balancé
3go de RAM pour l'instance Tomcat. En surfant
(et les conseils d'un ingé sys de la maison),
je me suis aussi rendu compte que une mémoire
min imposait un hachage de la mémoire en montée
de charge (je me trompe ?). Du coup min = max =
3072m. L'instance à 3go dès le démarrage.
Ok, je pense que nous allons regarder ça de plus
près aussi. Ce serait bien qu'on nous donne ce
genre d'information dans la procédure d'installation.
Malhereusement les configurations de JVM sont
tellement spécifiques au hardware + JVM choisi
qu'il faut vraiment aller regarder dans la
documentation de l'éditeur de la JVM. Ainis pour
hotspot les configs "idéales" pour windows ne
sont clairement pas les même que pour solaris. Ni
même les default settings... Donc selon votre
OS/Hardware, il faut rechercher un peu sur
internet les pages qui mentionnent comment "fine
tuner" votre JVM. Et ensuite il faut faire des
tests. C'est long et fastidieux et
malheureusement de la "faute" des vendeurs de
JVM. Malherueusement en tant qu'application Java,
nous ne pouvons que subir ce genre d'inconvénients nous aussi....
(ex de pages:
http://java.sun.com/docs/hotspot/index.html
http://java.sun.com/performance/reference/whitepapers/tuning.html
)
Cette config est ok, car mes ralentissements
sont au moment d'un listage des pages (genre
ajouter une page et la lier à une existante...)
où le serveur MySql plafonne à 99%.
Sinon, pour le reste, c'est rapide.
Oui, je suis toujours impressionné par le nombre
de requêtes SQL que l'application génère, en
particulier dans un contexte sans cache (édition).
Et oui. Et ceci risque d'aller en s'empirant avec
le support de standards tels que JSR170 (ou
bientôt 283). Le problème c'est la granularité
très fine des propriétés, des droits, des
ressources pour chaque objet de contenu
disponible sur une page (sachant qu'une page type
peut facilement avoir plusieurs centaines voire
plusierus milliers de champs différents). Donc
soit on prend une approche à la wiki (un seul
droit pas page, une seule version, etc...) ce qui
évidemment facilite bcp le système de requêtes,
soit il faut aggréger dynamiquement champs après champs.
Bon ok, le modèle de BD de Jahia n'est pas
parfait non plus. Ceci est dû au fait que nous
avons d'un côté une pression pour rajouter des
nouvelles fonctionnalités (dans Jahia 5.0 par
exemple: les métadonnées, le time based
publishing, les imports/exports, les workflows
distincts par objet de contenu, les copies liées
d'objets de contenu, ...) et de l'autre une
pression des clients existants pour qu'il y ait
le moins de "casse" possible au niveau de l'API
ou de leur set de template. L'un dans l'autre
nous sommes donc obligés de réutiliser certains
modèles de bases de données qui n'avaient
clairement pas été originellement conçu pour
supporter toutes ces fonctionnalités et qui
mériteraient d'être complètement revus.
Finalement dans Jahia 5.0, le cache frontal (par
fragment dans Jahia 5.0 et nons plus par page
entière) est également activé en mode édition. Il
est en plus désormais possible de découpler le
serveur dit de "processing" des serveurs
d'édition/consultation. Ainsi, quand un
utilisiateur décide de valider 100 pages, Jahia
lui rend directement la main et un job est envoyé
dans la queue du serveur de processing pour
traitement. Vu que le hardware coûte aujourd'hui
moins cher que des jours/homme de
fine-tuning/optimisation/audit de code/... la
solution de rajouter plus de machines avec des
rôles dédiés me semble la bonne approche.
Merci pour ce retour d'expérience... cela me
donne un autre point de vue très pertinent.
P.S: Pour Jahia 4.0, si vous voulez booster les
performances du moins en mode live, vous pouvez
déjà insérer des fragments de cache (ex:
taglib HTML de OSCache) sur vos menus (avec par
exemple une expiration à 10 minutes - au pire le
site live aura 10 min de décalage avec la réalité
des données). Il en va de même pour les "boxes"
qui effectuent des filtres complexes sur des
milliers de containers. Bref en cachant les pages
complexes et les menus, vous devriez déjà gagner énormément en performance.
Pareillement, on ne peut que s'améliorer à
échanger à propos de nos expériences.
Sébastien
Sébastien Nadeau
Technicien en informatique
Bibliothèque de l'Université Laval
418-656-2131 poste 6815
Avis relatif à la confidentialité
<http://www.rec.ulaval.ca/lce/securite/confidentialite.htm>
