Il faut bien comprendre la signification de ce Bench...
Il ne compare ni les fonctionnalitées, ni la souplesse, ni même les CMS... Il ne compare que les systèmes de caches. Et il permet de noter une très nette différence entre quelques technologies de cache disponibles aujourd'hui.
En effet, je n'ai rien contre Templeet (que j'aprécie), mais c'est plus son cache que le reste qui fait la différence. Et un cache du même type (ie même technologie) aurais significativement les mêmes résultat. Templeet peut donc se féliciter d'avoir un des (sinon le) meilleur systèmes de caches disponibles aujourd'hui...
Je parles en conaissance de cause, j'ai déjas implémenté cette technologie (pages statiques, génération dynamique sur redirect du 404, daemon pour vider le cache selon divers critères) en perl pour différents sites, et la différence est énorme... Le plus impressionnant fut de passer un gros site (plus de hits que LinuxFR) d'un système sans cache (tout le site était géré par un gros script perl de plus de 5500 lignes et des squeletes) où la charge de passait jamais en desous de 8 sur un bi-p3 700MHz 768Mo de ram à un système de cache (quasi-similaire, légèrement adapté à certaines contraintes) où le gros script n'est (quasiement) jamais appellé, ce qui descend la charge à moins de 1 contament sur la même machine (sauf pics dus à diverses opérations externes au site, genre recompil de kernel :D)
PS : pour relativiser le cache il faudrait connaitre le délai de chaque test, le délai d'expiration de la page, MAIS AUSSI le nombre de hits qui expirent la page, car certains systèmes considèrent une page expirée après un certain nombre de hits, ou un certain évènement...
# Attetion au piège!
Posté par _PinG _ . En réponse à la dépêche Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick. Évalué à 4.
Il ne compare ni les fonctionnalitées, ni la souplesse, ni même les CMS... Il ne compare que les systèmes de caches. Et il permet de noter une très nette différence entre quelques technologies de cache disponibles aujourd'hui.
En effet, je n'ai rien contre Templeet (que j'aprécie), mais c'est plus son cache que le reste qui fait la différence. Et un cache du même type (ie même technologie) aurais significativement les mêmes résultat. Templeet peut donc se féliciter d'avoir un des (sinon le) meilleur systèmes de caches disponibles aujourd'hui...
Je parles en conaissance de cause, j'ai déjas implémenté cette technologie (pages statiques, génération dynamique sur redirect du 404, daemon pour vider le cache selon divers critères) en perl pour différents sites, et la différence est énorme... Le plus impressionnant fut de passer un gros site (plus de hits que LinuxFR) d'un système sans cache (tout le site était géré par un gros script perl de plus de 5500 lignes et des squeletes) où la charge de passait jamais en desous de 8 sur un bi-p3 700MHz 768Mo de ram à un système de cache (quasi-similaire, légèrement adapté à certaines contraintes) où le gros script n'est (quasiement) jamais appellé, ce qui descend la charge à moins de 1 contament sur la même machine (sauf pics dus à diverses opérations externes au site, genre recompil de kernel :D)
PS : pour relativiser le cache il faudrait connaitre le délai de chaque test, le délai d'expiration de la page, MAIS AUSSI le nombre de hits qui expirent la page, car certains systèmes considèrent une page expirée après un certain nombre de hits, ou un certain évènement...