Eric Kinoa a écrit :
Bonjour à tous,
Je reviens vers vous pour un "partage" d'informations.
Quelqu'un a-t-il une plate forme CPS possédant un nombre de
contributeurs supérieur à 100?
Accuse-t-il des soucis de lenteurs ("lenteurs" pour rester positif ;o))
Peut-il me dire si l'architecture en place ets du type :
- N° 1 : un gros serveur multi process avec des clients ZEO dessus (4)
? (8 Giga de RAM)
- N° 2 : un gros serveur avec des clients ZEO externe ?
- N° 3 : plusieurs instances autonomes (ZEOisable) reliées à un noyau
d'échange Central
- autre ...
Nous on tourne avec un serveur bi-proc (XEON 2.80GHz) (dualthread) avec
4Go de RAM, qui héberge des clients ZEO dispatchés à l'aide de POUND (il
y en a plus que 4, mais tu verra pourquoi après), lequel est en relation
avec un serveur à peu près identique complètement dédié à ZEO (c'est
rude en E/S d'avoir les clients et le serveur ZEO sur une même machine,
je n'ai jamais réussi à avoir des performances correctes dans ces cas là).
En frontal, un troisième serveur qui fait APACHE+SQUID (en proxy inversé).
Quelques chiffres : environ 3500 sections sur 10 niveaux, une ZODB qui
pèse un peu plus de 9Go à l'heure actuelle. En tout cas, les
performances avec cette architectures n'étaient ni pire ni meilleures
quand la base pesait moins lourd.
L'authentification se fait assez rapidement (LDAP également), mais tout dépend
ensuite de ce qu'il y a à afficher une fois que le logged_in a fait sa
redirection : plus on a de droits, pire c'est !
Pour sauver les meubles, j'ai des clients mono-threads (à cause des problèmes
de conflits d'accès aux objets) répartis de la façon suivante :
- 1 pour les pièces jointes à télécharger (downloadFile)
- 2 pour les consultations anonymes (refus des cookies __ac)
- 2 pour les recherches (search_form, qui peut rapidement écrouler tout le site)
- 4 pour les utilisateurs authentifiés (uniquement pour ceux disposant de
cookies __ac)
Ca peut paraître bizarre comme ça, mais comme POUND ne peut pas savoir si les backends prévus seront
"plutôt occupés" ou "plutôt libres", on peut espérer que statistiquement une nouvelle
requête sera dispatchée sur un serveur capable de la traiter.En tout cas, c'est mieux qu'à l'époque où j'en
avais un seul pour chaque "domaine". Maintenant, en faudrait-il encore plus ? Je ne sais pas.
Pour les visiteurs anonymes, il n'y a pas de soucis : c'est essentiellement le
contenu en cache qui est rendu, donc on à presque les perfs du statique.
Pour les contributeurs, c'est variable (selon comment on tombe). Si quelqu'un a
accès à beaucoup de workspaces et qu'il en affiche la liste, l'instance est
complètement gelée jusqu'à ce que l'affichage soit terminé. Et donc
performances inacceptables pour les autre gens qu'elle sert.
En fait, c'est pareil pour toutes les opérations qui mettent en jeu un nombre
important d'éléments (documents en attente de validation, arborescences, ...)
et souvent difficile à supporter pour les gens avec des droits d'admins à un
haut niveau de l'arborescence.
Pour le reste (création, modifs, ...) ça peut aller.
Quand ça va bien, c'est très bien mais on peut rapidement se retrouver avec des
situations de ralentissement très gênantes, trop fréquentes à mon goût.
C'est vrai que c'est dur à défendre et à promouvoir face aux petits CMF plus
rapides que l'éclair (car beaucoup de nos contributeurs n'en font pas plus avec
CPS qu'avec autre chose en PHP par exemple). Mais bon, je résiste et j'espère
qu'on trouvera quelque chose pour mettre des images partout en WYSIWYG, ça les
calmera!
On verra bien si les versions les plus récentes de tous les éléments améliorent
les performances, enfin surtout de mieux les gérer.
Je n'ai jamais testé PLONE autrement que tout seul dans mon coin (et le choix
de CPS avait déjà été arrêté) donc je ne peux pas te donner de comparaison.
_______________________________________________
cps-users-fr
Adresse de la liste : [email protected]
Gestion de l'abonnement : <http://lists.nuxeo.com/mailman/listinfo/cps-users-fr>
