"je pense qu'il faut plutôt avoir un système scalable reposant sur un répartiteur de charge, plutôt que de rendre statique artificiellement des pages sur un site..."
C'est pourtant ce que font les RAMCaches . ? :)
Néanmoins, je serais très intéressé pour voir les courbes nb request / cpu load sur un tel système en production. Mais aussi sur le nb de hits max possibles.
Je me suis longtemps penché sur le pb des perfs de Plone / CPS et autre .. et je suis arrivé à la conclusion suivante. Le fautif n'est pas Plone ou CPS .. mais la génération des pages (notamment les ZPT).
En guise d'exemple, il suffit de faire quelques benchs de génération de page sur ZPT pur et python pur .. pour contaster l'ampleur des dégats. Dans le pire des cas j'ai obtenu des ratios de 10.
( les tests utilisaient :
- ZPT ( standard )
- OpenTAL
- avec / sans Zope ..
- au sein de Plone et de CPS
- sans Zope ..
( tous les cas on était étudié ).
Résultat OpenTAL un peu meilleur que ZPT standard ..( surtout sur des namespaces i18n par ex ). Mais réellement lent comparé à d'autre alternatives ( notamment Cheetah )
A retenir aussi le fait d'utiliser Localizer génère une baisse des perfs de 10% sur le rendu d'une page ... ce qui n'est pas énorme mais peu faire la différence.
Malheureusement, il n'y a pas d'alternative. J'ai découvert il y a peu les STL (http://ikaaro.org(...)). qui offre des perfs un peu meilleures que les standards ZPT, mais je n'ai pas encore eu le temps de faire une vrai étude comparative.
En conclusion, il FAUT utiliser un system de cache ( dans Zope ou externe .. ou les deux ). Mais ce genre de chose est en général incompatible avec la nature des CMS, car ils sont "user centric".
Perso je suis tenté de penser que cela dépends réellement de l'application et qu'il faut le designer au sein Zope ( Prévoit le fonctionnement des objets dans les FSCaches par ex )
[^] # Re: Hébergement Zope
Posté par Jérome K . En réponse à la dépêche Hébergement Zope. Évalué à 3.
C'est pourtant ce que font les RAMCaches . ? :)
Néanmoins, je serais très intéressé pour voir les courbes nb request / cpu load sur un tel système en production. Mais aussi sur le nb de hits max possibles.
Je me suis longtemps penché sur le pb des perfs de Plone / CPS et autre .. et je suis arrivé à la conclusion suivante. Le fautif n'est pas Plone ou CPS .. mais la génération des pages (notamment les ZPT).
En guise d'exemple, il suffit de faire quelques benchs de génération de page sur ZPT pur et python pur .. pour contaster l'ampleur des dégats. Dans le pire des cas j'ai obtenu des ratios de 10.
( les tests utilisaient :
- ZPT ( standard )
- OpenTAL
- avec / sans Zope ..
- au sein de Plone et de CPS
- sans Zope ..
( tous les cas on était étudié ).
Résultat OpenTAL un peu meilleur que ZPT standard ..( surtout sur des namespaces i18n par ex ). Mais réellement lent comparé à d'autre alternatives ( notamment Cheetah )
A retenir aussi le fait d'utiliser Localizer génère une baisse des perfs de 10% sur le rendu d'une page ... ce qui n'est pas énorme mais peu faire la différence.
Malheureusement, il n'y a pas d'alternative. J'ai découvert il y a peu les STL (http://ikaaro.org(...)). qui offre des perfs un peu meilleures que les standards ZPT, mais je n'ai pas encore eu le temps de faire une vrai étude comparative.
En conclusion, il FAUT utiliser un system de cache ( dans Zope ou externe .. ou les deux ). Mais ce genre de chose est en général incompatible avec la nature des CMS, car ils sont "user centric".
Perso je suis tenté de penser que cela dépends réellement de l'application et qu'il faut le designer au sein Zope ( Prévoit le fonctionnement des objets dans les FSCaches par ex )