Voici un petit article reprenant les résultats du benchmark, avec des graphiques assez parlants. Je décris le mode opératoire, les paramétrages divers utilisés, les résultats et donne une conclusion qui n'engage que moi. On y trouve les fichiers bruts de log issus des mesures, la feuille de calcul ayant généré les graphiques, ainsi que les copies statiques des pages utilisées.
Les résultats sont tellement disparates que je fais un petit point sur le mode opératoire de la solution gagnante.
Aller plus loin
- Benchmark (479 clics)
- Templeet (NdM: remplacé en 2021 par un lien archive.org) (103 clics)
- Zope (31 clics)
- SPIP (34 clics)
- OpenBrick (36 clics)
# Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Jiquem . Évalué à 4.
Non bon ok c'est pas drôle !
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à -2.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Rafael Pinilla . Évalué à 10.
D'origine, le DocumentRoot du VirtualHost apache pointe _directement_ sur le cache.
C'est ça _LE_ killing feature de Templeet, ce qui le fait aller si vite.
Je sais, c'est pas facile à envisager, c'est tellement à l'opposé des autres systèmes...
Si perte de charge il y a, elle est due vraisemblablement due à l'évaluation des expressions régulières par les directives mod_rewrite.
Enfin, c'est la seule raison que je vois.
Je vais essayer de voir les perfs de drupal. Je me suis laissé dire qu'une requète SQL était lancée à chaque connexion. si c'est le cas, on revient au cas classique où c'est le petit cocode chéri du développeur qui prend la main pour décider, et perd donc du temps.
[^] # Comparer carottes et jantes d'AUDI 80 ?
Posté par Rafael Pinilla . Évalué à 10.
Je rappelle à tous ceux qui liront le bench qu'il s'agit içi uniquement d'un test de charge, effectué de but en blanc parce que mon système est destiné à tourner sur une confuguration minimale. Aussi j'ai utilisé les fonctionnalités évoluées de chaque logiciel pour générer une page (de taille aussi égale que posible) mise en place par un système dynamique. Une fois cette page préparée, charge au système de la servir du mieux qu'il peut, aussi vite que possible, sans plomber la charge d'un pauvre processeur anémique. En référence j'ai choisi Apache, car c'est _la_ référence. Il fonctionne vite et bien. Il a fait ses preuves. il est livré d'origine. Il est libre. No troll please.
[^] # Re: Comparer carottes et jantes d'AUDI 80 ?
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 4.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Pooly (site web personnel) . Évalué à 4.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Rafael Pinilla . Évalué à 6.
Ca donne du 7.3 req/s pour 145Ko/s. La _seule_ différence, c'est que mon domumentroot pointait sur /var/newww/nexus/
Je rappelle qu'il s'agit des templates de linuxfr, les mêmes que ceux qui s'exécutent en pointant sur http://linuxfr.org/pub/(...)
J'étais tout fier des résultats, j'avais posté des résultats à l'arrache dans un newsgroup lost-oasis.
Même dans ce cas, c'est plus léger et plus rapide.
Ce n'est que quand quelques habitués du chan irc en question m'ont demandé d'inclure Zope et SPIP ce week end que j'ai tenté d'étendre le bench et de rendre un truc propre. Ca devait pas me prendre plus d'une heure. Ca ma pris un un jour.
Avec mon 145Ko/ et 7.3req/s J'ai pointé mon nez sur #templeet en donnant mes résultats. Là Fabien m'a rit au nez en arguant que j'avais _forcément_ raté une étape, car templeet ne pouvait _pas_ être si loin d'Apache.
Il m'a mis le nez sur la doc, sur la ligne sur laquelle j'étais passé convaincu d'avoir positionné la variable $pagecache. Mais non crétin que je suis, c'est le documentroot qu'il faut pointer dessus.
Et là: doute. Mais alors comment ça marche ??? A non mais attends, heu, ben oui ça doit marcher. J'essaie voir. Et là ça va vite, très vite.
C'est pas de ma faute, ça va vraiment vite ce truc.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Fabimaru (site web personnel) . Évalué à 1.
Que donnent les perfs dans le pire cas (tous les utilisateurs sont authentifiés et ont le droit à des [+] et [-] à coté de chaque commentaire) ?
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par tinou . Évalué à 2.
Du peu que j'en connais, Drupal est sympa, fonctionnel, et très complet.
Effectivement, je crois qu'il utilise une requête SQL à chaque connexion, puisqu'il stocke son cache dans sa base de données, dans la table 'cache'.
--
Tinou
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Pascal Terjan (site web personnel) . Évalué à 5.
LOL
# Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Misc (site web personnel) . Évalué à 10.
Il faut prendre en compte chaque aspect , et comme chaque benchmarck, je trouve que c'est réducteur d'occulter tout ou presque pour mesurer uniquement la vitesse.
Par exemple, j'aurais voulu voir des solutions comme slash, ou l'utilisation d'apc.
Savoir comment on peut tuner apache, pour encore accelerer, ou comment tuner mysql, etc.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Pierre Tramo (site web personnel) . Évalué à 7.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Cyril . Évalué à 1.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Pierre Tramo (site web personnel) . Évalué à 1.
Templeet compense sa lenteur par un systeme de cache mais si tu en fait un en php, templeet n'a plus aucun avantage.
Je ferais bien un benchmark pour le démontrer(pour le peu qu'un benchmark puisse démontrer qqch) mais je suis certain que la news ne passerait jamais ici.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Pooly (site web personnel) . Évalué à 3.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Erwan . Évalué à 2.
Templeet a aussi l'avantage de simplifier d'autres taches.
Mais tu as raison: si tu reecris templeet (gestion du cache, du multilingue, des acces BD), templeet n'a plus aucun avantage. Mais faudrait un benchmark pour demontrer ca.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Anonyme . Évalué à 3.
Ben pas les tâches d'écriture et de maintenance des fameux templates en tout cas.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Ano nyme (site web personnel) . Évalué à 1.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Rafael Pinilla . Évalué à 4.
J'ai déjà indiqué plus haut les résultats sans cache: 7.3req/s et 145Ko/s pour les templAtes (compliqués :) de linuxfr.
En fait, TemplEEt fonctionne globalement comme ça (j'ai tracé la chose pour ne pas mourir crétin):
Erreur 403|404 => Execution de templeet.php qui lance le chrono (facteur ralentisseur, tiens), décode l'argument:
si argument=rien de connu => page d'erreur:
Sinon, il lit le templAte correspondant à l'argument:
Ouverture du TemplAte en question:
Mise en cache des include éventuels (héhé)
Parsing de haut en bas du templAte.
A chaque fonction, un appel vers ./module/nom_du_module.php , avec passage des arguments, ( un module gère de une à plusieurs fonctions mot-clé templEEt) qui bosse et revient au noyau de templEEt qui poursuit.
A la fin du templAte, le chrono est arrété, et le footer éventuel indiquant le temps d'exécution est éventuellement indiqué.
En gros, c'est comme ça que ça fonctionne, et ça va plus vite que SPIP même sans aucun cache. Pire, il écrit le cache à chaque fois qu'il est exécuté dans ce cas, il me semble, vu que comme il le templAte n'est sensé s'exécuter QUE en cas de cache absent, il est inutile de vérifier. Il faudrait désactiver l'écriture du cache pour voir.
En fait, ça va bien plus vite que tu ne penses.
Voilà.
Si un des créateurs de Templeet pense que j'ai dit des conneries, merci de rectifier.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 3.
Le lancement du chrono ne consomme pratiquement rien, c'est juste une information qui permet de savoir si une page s'affiche plutôt rapidement, ou lentemenet, plus rapidement qu'avant, etc. Ce n'est pas le temps réel vu que le chargement de PHP dans Apache consomme déjà, par exemple, et n'est pas compris dans le chrono.
Ce que tu appelles l'argument, c'est en fait l'url demandé, tout simplement, s'il ne reconnait pas l'url, alors il affiche une erreur404, normal (mais templatisée quand même pour pouvoir la changer). S'il trouve le template, il l'évalue. Ensuite les fonctions dans les templates. Comme PHP est d'une lenteur incroyable pour lire son propre code, les modules ne sont chargés que lorsqu'une fonction s'y trouvant est appelée dans un template, on gagne réellement en rapidité comme cela. Tu n'as pas d'appel du module ou autre, c'est juste que le module est chargé la première fois qu'on en a besoin, ensuite il ne l'est plus vu qu'il est en mémoire, et la fonction marchera toujours.
Pour le cache, on peut toujours activer le cache des templates, d'ailleurs je pense qu'on va l'intégrer dans l'installeur. Ensuite le cache des pages, on peut aussi l'activer sans vraiment avoir de système de page 404, mais c'est plus lent vu qu'il faut quand même charger PHP, ce qu'il faut éviter vu que c'est une -biip- côté performance.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Beretta_Vexee . Évalué à 2.
De plus slashcode est plus un gestionaire de contenue t'elle qu'un PHP-NUKE qu'un systéme a vocation réellement generaliste comme SPIP, ZOPE ou Templeet.
# Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par arnaud . Évalué à 3.
Si Rafael Pinilla lit ce post, peut-il remédier à ça ?
merci d'avance
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par naibeD . Évalué à 6.
http://linuxfr.org/images/load/load-yearly.png(...)
Les résultats sont réellement impressionants ;)
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Rafael Pinilla . Évalué à 1.
# Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Encolpe DEGOUTE (site web personnel) . Évalué à 10.
Vous devriez y jeter un oeil et refaire des benchmarks.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par pas_moi . Évalué à 8.
Après avoir regardé comment les tests ont été réalisés, j'aurais tendance à devenir grossier, surtout quand j'entends parler de graphiques parlants: je ne vois pas bien comment on peut comparer des valeurs qui ne veulent rien dire entre elles. À part la comparaison Apache/Templeet qui semble se baser sur le même document, les autres serveurs sont utilisés complètement différemment...
En voyant la configuration Apache du serveur Templeet, je comprends enfin d'où viennent ses performances dont tout le monde parle tant :-) Par contre, il faut savoir que Zope dispose de ce genre de mise en cache des données, même si ce cache n'est géré qu'en mémoire. Il faut aussi noter que les méchanismes d'invalidation des caches sous Zope seraient sûrement à revoir: pour l'instant, je n'ai pas trouvé comment ne retirer que certaines données d'un cache, je suis donc obligé de vider entièrement un cache même si je sais que certaines des données auraient pu y être gardées... heureusement qu'il est possible de créer plusieurs caches!
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Rafael Pinilla . Évalué à 5.
Il ne faut pas perdre de vue que la plateforme matérielle utilisée est modeste, aussi les différences sont augmentées par la lenteur du processeur.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par pas_moi . Évalué à 1.
Je ne peux pas franchement dire que je maîtrise Zope, d'autant que j'ai encore quelques problèmes avec les paramètres de la ZODB, mais l'utilisation d'"Accelerated HTTP Cache Manager" associés à un frontal Apache en reverse-proxy/cache et de "RAM Cache Manager" m'a déjà permis d'atteindre des performances très raisonnables, même sur des machine de type VIA Eden. Par contre, j'ai du m'embrouiller dans certains paramètres Apache car il lui arrive de nettoyer son cache sans pour autant redemander les pages à Zope... résultat: au bout de quelques heures, Apache renvoie des documents vides :-(
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Luc Stepniewski (site web personnel) . Évalué à 1.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par pas_moi . Évalué à 4.
Un "HTTP Cache" permet d'ajouter des entêtes de gestion de cache aux réponses HTTP du serveur Zope... ces entêtes servent à annoncer aux navigateurs pendant combien de temps les documents servis doivent être gardés en cache (c'est très utile pour les images et les CSS, entre autre). En plaçant un Apache ou un Squid devant un Zope, les documents contenant de tels entêtes peuvent être gardés sur le reverse-proxy; ainsi, la première requête sera relayée à Zope, et toutes les suivantes seront directement servies par le reverse-proxy, et ce tant que le document n'aura pas expiré du cache.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Luc Stepniewski (site web personnel) . Évalué à 1.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par pas_moi . Évalué à 2.
Personnellement, je ne sais pas pour quoi c'était prévu, mais je vois à quoi ça sert :-) Je vois Zope plus comme un moteur de génération de document que comme un serveur web... bien sûr, la gestion des entêtes HTTP me ramène souvent à la réalité.
Dans le cas d'un Zope sans reverse-proxy cache, un document demandé par x clients différents n'utilisant le même proxy fera travailler Zope x fois. En utilisant un reverse-proxy cache et un "HTTP Cache", seul le premier client fera travailler Zope, les autres étant directement servis par le reverse proxy... je trouve que ça fait quand même une grosse différence au niveau de la charge du serveur Zope!
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par dr . Évalué à 5.
Il faut mettre Apache en frontal, ou Squid (la derniere version de Zope integre une gestion fine de la cooperation avec Squid) et tu auras le meilleur des deux mondes (Zope pour du serveur d'application, et Apache/Squid pour servir les pages résultantes).
Fais aussi attention aux url relatives/absolues afin que Zope ne recalcule pas ses objets a chaque fois.
Si ton site est statique, ou ne bouge que de temps en temps, c'est encore plus efficace.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Sébastien Munch . Évalué à 8.
Je dois avouer que j'ai vu beaucoup de cas où Zope était en frontal...
Mettre Apache devant fait tellement gagner que ça ?
Même si le serveur est une toute petite configuration ? Ou alors *surtout* dans ce cas-là ?
Ca m'intéresse, car mon OpenBrick a un p'tit Zope dessus, alors si je pouvais l'accélérer facilement, ça ne me dérangerait pas...
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par pas_moi . Évalué à 2.
Boarf, on voit aussi des IIS et des Exchange branché directement sur Internet... ce n'est pas pour autant que c'est une bonne idée :-)
Mettre Apache devant fait tellement gagner que ça ?
Ça peut faire énormément chutter la charge du serveur Zope, mais ça demande un peu de travail (ie: ajouter Apache ne fait généralement pas gagner de perf. s'il n'y a pas un minimum de gestion de cache déjà en place sur Zope).
Ca m'intéresse, car mon OpenBrick a un p'tit Zope dessus, alors si je pouvais l'accélérer facilement, ça ne me dérangerait pas...
Je n'ai pas utilisé ce document mais en le survolant rapidement, il me semble présenter une bonne technique de mise en cache: http://www.nexedi.org/Members/jp/faq/accelerate-zope.stx(...)
Cela n'empêche pas de se renseigner sur la gestion des caches HTTP par les navigateurs et les différents proxys :-)
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Luc Stepniewski (site web personnel) . Évalué à 0.
D'où tiens tu ces informations ? Est-ce que tu installes souvent des Zope chez des clients ? L'installation de Zope avec Apache/Squid était intéressante il y a plus de deux ans, pour profiter du cache pour les images, ou pour le virtualhost. Mais cela fait un bon moment que cela n'est plus nécessaire. Zope intègre une gestion des virtual host beaucoup plus fine, et intègre des objets de type 'cache' (plusieurs types, même) qui peuvent être associés à n'importe lequel des éléments de ton zope. Cela peut être une partie de page, un calcul, ou des pages entières.
Je recommande d'installer Zope en frontal, sans aucune hésitation.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par dr . Évalué à 1.
Mais le Zserver/medusa ne semble pas adapté a supporter un DOS.
D'ou l'usage de Apache en mod_proxy ou Squid en frontal.
On n'utilise Apache que pour ca actuellement.
Mais bon ... l'important c'est bien la puissance fonctionelle de Zope comme paradigme (ouhhh .. ca sonne bien ça ;-)
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Luc Stepniewski (site web personnel) . Évalué à 1.
Le but de Zope est d'utiliser ses fonctionnalités *applicatives* telles que les workflows, la gestion de la sécurité, la génération dynamique de contenu adapté à tout un ensemble de paramètres/autres objets. Tout logiciel qui fonctionne de cette manière est vulnérable à des dénis de services si quelqu'un fait des requêtes en masse (quoique, ça fait plus de hits :-).
Mettre un Apache ou un Squid ne servira à rien dans ce cas, puisque les pages sont supposées être générées différemment (quasiment) à chaque fois). Si ce n'est pas le cas, alors n'utilise pas Zope, utilise un Templeet ou équivalent.
Pour éviter ces problèmes, faire de la répartition de charge est une solution, ou faire de la qualité de service sur le firewall devant, sont quelques-unes des possiblités qui me viennent en tête. Mais mettre un Apache, non, pas vraiment.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par dr . Évalué à 1.
Je m'abreuve aux meilleures sources (shane@zope.org)
http://mail.zope.org/pipermail/zope-coders/2002-March/000893.html(...)
Nous avons aussi besoin de SSL pour l'admin, le provider a un Apache général, etc ... d'ou l'usage d'apache.
On est vraiment dans un cas ou effectivement tout est dynamique et personalisé (tu le connais bien ;-)
Mais j'ai noté avec attention tout ce que tu dis, et on va regarder ca de plus pret quand on va faire évoluer notre application.
De toute facon avoir ZEO est indispensable effectivement en cas de montée en charge.
A une prochaine, luc.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Luc Stepniewski (site web personnel) . Évalué à 1.
"[Zope] is not as prepared to deal with that threat as Apache or Squid."
Ce qui est évident. Donc, je confirme: FUD.
De même dans la conclusion de ce mail, il est bien dit que Zope n'a pas spécialement de problème de DoS, autres que des personnes envoyant des requetes répétées. Mais comme je l'ai dit, *tous* les serveurs applicatifs y sont vulnérables.
"But I don't think it's any more vulnerable to other kinds of attacks
than other HTTP servers. It doesn't use the filesystem and never runs
with root privileges".
Donc, je ne vois pas du tout en quoi ce mail vient défendre tes arguments, je dirais même au contraire :-)
Pour le SSL, Zope possède deux modules pour faire du SSL de façon native, l'un étant semi-extérieur, et l'autre permettant de gérer les certificats en interne dans Zope, ce qui n'est pas le cas avec Apache.
Alors, je ne vois toujours pas de raison valable d'utiliser Apache.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par dr . Évalué à 1.
too fast.
Ce qui a été un élément de choix pour nous car en production (on a des uptimes de plus de 70 jours sans probleme, et encore c'est pour des questions de reboot zope du a des maj de produits ;-).
Maintenant on est quand meme sur de la maltraitance d'insecte ;-) quand on mesure TOUS les avantages fonctionnels de Zope comme tu l'as si bien dit.
BEAUCOUP plus important en termes de sécurité, Zope a un modele de sécurité natif, ce qui évite de découvrir des failles de sécurité dues a la programmation ou des ajouts de modules pas prévus pour cela dans les autres plate-formes. Et ca c'est priceless !!
Donc au final on est tous d'accord : Zope en plus d'etre fonctionellement performant, il est rock solid.
Bon, je vais me recoucher.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Luc Stepniewski (site web personnel) . Évalué à 2.
> http://mail.zope.org/pipermail/zope-coders/2002(...)
C'est vrai que Shane Hathaway est le dieu vivant du Zope, mais tu devrait regarder ta référence un peu mieux. Ce n'est pas Shane qui a dit qu'il pense que Zope n'est pas assez robuste (FUD), c'est un certain Toby Dickenson. D'ailleurs Shane défend la robustesse de Zope dans son mail, je te ferais remarquer. Lis le mail jusqu'au bout :-)
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Rafael Pinilla . Évalué à 1.
C'est à un pouillème la même taille.
Vérifies.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par pas_moi . Évalué à 3.
C'est bien là le seul point commun au niveau des tests effectués.
On sait très bien qu'en demandant x fois le même document à Templeet il ne sera généré qu'une seule fois et ensuite il sera toujours renvoyé par Apache donc je ne vois pas comment on peut appeler ça un test de Templeet.
À la limite, ils auraient comparé la vitesse de génération d'un même document dans les différents langages de template de ces outils, ça aurait pu commencer à vouloir dire quelque chose (et encore, on peut toujours critiquer la façon de coder dans chaque langage) mais là je soutiens que c'est du n'importe quoi...
Pourquoi ne pas tester l'adhérence sur sol humide (toujours le même taux d'humidité) d'un char Leclerc à 10km/h, d'une Ferrari à 200km/h (en seconde, quoi) et d'une BX à 160km/h?
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Gruik Man . Évalué à 1.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Fabimaru (site web personnel) . Évalué à 2.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par didbaba . Évalué à 1.
# Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par XHTML/CSS inside (site web personnel) . Évalué à 7.
Mais bon, il a aussi d'autres avantages...
En tout cas, je ne pensais pas que templeet était aussi bon.
(je sais ce ne sont que des benchs, mais quand même)
A+
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par _alex . Évalué à 5.
Zope, SPIP et Templeet ne sont pas fait du tout de la même façon, tout dépend de ce qu'on veut faire avec.
(sinon manque la solution programme en C optimisé pour un site en particulier)
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par dr . Évalué à 10.
<mode troll on>
C'est pas trop pertinent de comparer Apache (qui sert des pages) et Zope (qui a un modele de sécurité natif, qui accede aux objets en ftp, http, webdav, xml-rpc en natif, qui fait du undo sur les objets (!), qui sépare clairement logicue, contenu et présentation, qui se connecte aux sgbdr sans rien changer a la logique ou a la presentation, qui dispose de Workflow génériques en natif, et j'en passe) pour un CMS.
Combien de temps va tu passer a mettre en place une solution qui soit un __vrai__ CMS comme Collaborative Portal Serveur www.cps-project.org, voire comme Plone www.plone.org ou Silva (qui tournent tous les 3 sous Zope et qui concernent des publics et fonctionalités différentes) ?
A moins que ce que tu nomme CMS soit plus un site de news/forum de type linuxfr, auqual cas Zope n'est pas le plus adapté car bien trop puissant fonctionellement et beaucoup plus adapté a un site ou tout est computé a la volée (pour du CMS justement) ;-)
<mode troll off>
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Pascal Terjan (site web personnel) . Évalué à 3.
Heu je ne vois pas le rapport. Si le contenu ne change pas, pourquoi recalculer sa présentation ?
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par dr . Évalué à 1.
Dans du CMS les pages sont très dépendantes de la personne qui consulte, du modele de sécurité des espaces, du contexte, du mode d'acces, des roles et autorisations, des actions possible et en cours, de l'etat du document dans des cycles de workflow, de l'age du capitaine, etc... Donc tout doit etre calcule a la volée.
Quand le contenu ne dépend pas de tout ca, effectivement il n'y a pas besoin de recalculer systematiquement.
Donc "si le contenu ne change pas, on ne recalcule pas sa représentation (ni son contenu ce qui est encore différent)"
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Alberto . Évalué à 4.
A mon avis, dans de tres nombreux cas on est dans un etat intermediaire (il faut garder la possibilite de generer dynamiquement mais dans de nombreux cas c'est inutile car deja genere). Imagine un journal (pex lemonde) je suis sur que 90% des hits vont sur 10% des pages ! Un peu comme quand 90% du temps de calcul est passe dans 10% du code. Bref, je ne crois pas a la necessite (pour un gros CMS, si il y a 20 poilus ca ira de toute facon..) de recalculer systematiquement les pages !
Une petite question. Est-ce qu'il est possible de cacher des bouts de pages html. Et de recalculer que les bouts qui ont change. J'imaginais une page avec l'heure (linuxfr a la date, pourquoi pas l'heuere).
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par dr . Évalué à 2.
Par contre avant de __rendre__ la page ou les bouts de page, il faut bien computer les conditions, afin de voir ce qui doit changer ou pas.
Et quand tu es dans du CMS avec de tres nombreux parametres potentiels, c'est cela qui peut prendre du temps. Pas forcement le rendu de la page.
# Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par tene . Évalué à 9.
Le reste, amha, ne compare pas des choses équivalente... (on parle de langage, de système de cache, de site, ... etc).
Ceci dit, c'est chouette de se dire que la cache de templeet est efficace... j'espère que ça motivera certaines personnes à penser leur page dynamique de façon à être "cachable"... ce qui n'est pas toujours évident... (parce que certains sites sont affreusement lent!)
# Portnawack
Posté par Infernal Quack (site web personnel) . Évalué à 10.
Pourquoi pas comparer un chat, un pigeon et un poisson rouge ?
Le scoop : le poisson rouge nage plus vite :)
- Templeet est un moteur de template qui implémente un gestion de cache.
- Zope est un serveur d'application en python.
- Spip est un gestionnaire de contenu.
- Apache est un serveur web
Bref ils se complètent plus qu'ils ne sont concurrents.
On pourrait même imaginer porter SPIP et Templeet en python et faire un système multi-couche
SPIP-like (pour la gestion du contenu)
----------------------------------------------
Templeet (pour la gestion de cache)
----------------------------------------------
Zope (moteur applicatif)
----------------------------------------------
Apache (serveur de page statiques)
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Portnawack
Posté par feth . Évalué à -4.
[^] # Re: Portnawack
Posté par Xavier Antoviaque (site web personnel) . Évalué à 4.
[^] # Re: Portnawack
Posté par atlexx . Évalué à 3.
[^] # Re: Portnawack
Posté par Erwan . Évalué à 3.
Et pourquoi ne pas comparer les performances de Linux avec celles du Pentium 4 ?
[^] # Re: Portnawack
Posté par iug . Évalué à -1.
[^] # Re: Portnawack
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
"La première sécurité est la liberté"
# Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Manico . Évalué à 1.
Un peu de grain a moudre, zionsys, http://www.zenzile.net/theme24.php(...) (qui est en train de changer de nom mais c'est autre chose) utilise le meme principe, selon la configuration avec ou sans interaction avec php (cache en lecture directe ou cache avec relecture pour des elements dynamiques).
# Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Antoine . Évalué à 10.
Je reprendrai la même remarque qu'un autre intervenant : certes Templeet est vainqueur et largement. Mais pour obtenir le même niveau de performances avec un autre outil (même cette grosse daube de PHP-Nuke, oui oui), il suffit de... mettre un proxy devant. C'est en effet ni plus ni moins le fonctionnement de Templeet. Ce qui n'enlève rien à son mérite, d'ailleurs, si c'est ce que l'on cherche : témoin les stats faramineuses de linuxfr, sur une machine relativement modeste ; je pense que SPIP, sur une machine équivalente, commencerait à avoir du mal (néanmoins SPIP assure deux millions de pages par mois pour le Monde Diplomatique, ce qui n'est pas rien non plus).
Sur les chiffres absolus, je suis un peu surpris, mais il est vrai que le processeur d'un OpenBrick ne doit pas être un foudre de guerre (pour ma part, sur un Athlon XP 2000 avec PHPAccelerator, j'obtiens une centaine de requêtes par seconde sous SPIP, et probablement plus de mille avec Apache/Templeet). Néanmoins, l'utilisation d'une plateforme légère ne me semble pas pertinente pour une solution à base de cache (que ce soit SPIP, Templeet ou autre) où la disponibilité de la machine est surtout cruciale lors du recalcul d'une page - il vaut mieux une machine mutualisée puissante servant N sites plutôt que N machines dédiées faiblardes servant chacune un site. De plus, l'expérience semble montrer (d'après le retour sur les listes de discussion) que le problème pour certains utilisateurs "moyens" est la durée de recalcul lorsqu'une page n'est pas en cache - certains hébergeurs très lents du type Free ou Online ont tendance à dépasser le délai imparti à PHP - plutôt que le débit en pages par seconde une fois que l'on passe par le cache. Mais ça dépend bien sûr des applications.
Sur le fond, il est évident que les performances sont du côté des solutions intégralement statiques type Apache ou Templeet (il aurait été intéressant d'ajouter un PHPNuke, pour admirer le carnage ;-)). Maintenant il faut ajouter que ces solutions n'apportent pas forcément un niveau d'intégration très poussé des fonctionnalités désirées par le webmestre. Tout dépend si l'on a envie de coder soi-même des choses à la main, ou si Templeet propose des frameworks plus "haut niveau".
Pour SPIP, j'ajouterai que le niveau de performances dépend des fonctionnalités activées, à savoir : syndication automatique, moteur de recherche. En effet ces fonctionnalités entraînent des calculs réguliers indépendamment de la mise en cache des pages retournées par le serveur.
Amicalement
Antoine.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 3.
Pour mon information, sur quelle machine, et avec quel type de charge ? C'est important quand même :)
[^] # Type de machine ?
Posté par Rafael Pinilla . Évalué à 1.
Non, sans plaisanter, il faut voir avec les pics, mais il doit falloir mettre des mips en pagaille pour que la charge ne monte pas.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Antoine . Évalué à 2.
Un autre critère est d'aller voir le site du Diplo (http://www.monde-diplomatique.fr(...)) et de constater que la navigation est fluide (hormis le sale bandeau de pub sous-traité à une régie externe ;-)) : ça ne donne pas une impression de "site dynamique" un peu poussif. La fréquentation est montée à trois millions de pages sur un mois dernièrement (Irak oblige).
Pour le reste, un "Apache Bench" depuis une machine bien connectée permet de se faire une idée plus précise des temps de latence (par exemple en comparant avec un fichier statique hébergé sur le même serveur, une image par exemple).
Pour répondre au commentaire du dessous : on ne peut pas reprendre un cumul mensuel et dire que cela représente N requêtes par seconde en continu. Les consultations Web sont très dépendantes de l'heure et du jour, il faut être prêt à tenir des charges de dix pages par seconde (plus pour Linuxfr) tout en assurant de préférence un envoi rapide des pages demandées.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par jeanmarc . Évalué à 1.
Selon moi, dans la vraie vie, ce n'est pas du tout important. A quoi ça sert d'annoncer 6 millions de requêtes/s en passant à templeet si à côté il faut tout reprendre à zéro, prendre une équipe pendant 6 mois avec une solution qui reste marginale?
Dans la vraie vie, on préfère quand même acheter une machine puissante (même surdimensionnée) et disposer d'un applicatif solide et facilement maintenable plutôt que tuner dans tous les coins pour atteindre le nirvana du meilleur rapport puissance/vitesse à tout prix.
Pour un petit projet personnel, ça pourrait avoir un intérêt.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Sébastien Munch . Évalué à 2.
Ouais, mais c'est tellement bien de pouvoir administrer toi-même ta machine ;)
# Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par jmh . Évalué à 7.
Vous connaissez la specification TAL? C'est la specification pour les templates "nouvelle formule" utilises par zope. C'est vraiment tres elegant AMHA.
http://www.zope.org/Wikis/DevSite/Projects/ZPT/TAL(...)
Un bon pote a moi a fait une implementation PHP:
http://laurent.bedubourg.free.fr/php/phptal/(...)
Quand a moi, je maintiens une version Perl sur CPAN:
http://search.cpan.org/search?query=petal(...)
Tout ca mis a part, petite question sur templeet... Vu que apparemment le cache == le document root d'apache, qu'est-ce qui vient invalider le cache? Un chtit script dans la crontab?
Peace,
Jean-Michel.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Pascal Terjan (site web personnel) . Évalué à 5.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par jmh . Évalué à 2.
* Par exemple, si tu veux importer des feeds RSS / XML dans ta page? Il faut bien trouver un moyen d'invalider ca!
* Si tu veux avoir une structure hierarchique et une bread-crumb-trail? Par exemple, tu as la page Accueil / About / Contact. Quelqu'un edite le titre de 'About' et le change en 'A propos'. Il faudra bien que la bread crumb trail sur ta page Accueil / About / Contact devienne Accueil / A propos / Contact.
Bref, purger le cache lors d'une modif c'est bien, mais ce n'est pas toujours applicable. Reste toujours l'option de mettre un script de nettoyage dans la crontab :)
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Jérome K . Évalué à 1.
http://savannah.nongnu.org/projects/opental/(...)
# Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Code34 (site web personnel) . Évalué à 10.
Est ce que quelqu'un aurait un lien vers un howto pour les débutants qui explique comment se servir de templeet ?
J'ai installé templeet, il y a quelques jours et je me suis posé la question: "mais après je fais quoi ????"
Au départ, je pensais que Templeet était un cms comme spip, il n'en est rien, c'est un langage de développement.
J'ai lu sur la liste de diffusion qu'avec templeet, on peut faire un site efficace en 5 minutes si on est agueri. Je suis totalement néophyte, et excusez moi je ne comprends rien.
Templeet a sans doute des qualités indégnables en terme de performances et en terme de qualité de code (ce site en est d'ailleurs une parfaite illustration).
Par contre pour les débutants comme moi c'est un peu raid de s'y mettre, car ce projet est très peu documenté. Je vais reessayer de me faire la main avec le weblog en exemple, mais ça serait assez bien un document qui explique comment faire une structure de page minimun.
Au départ, je cherchais un cms performant pour publier plusieurs sites sans me soucier du développement php car par experience creer un site php c'est beaucoup trop de temps de perdu, et ça n'est pas rentable.
Je suis convaincu qu'il est inutile de recreer ce qui existe déjà et qui est sans doute fait par des personnes plus expertes que moi.
J'ai donc cherché du coté de spip, mais apparamment spip c'est très limité en terme de présentation. Je vais peut etre trollé, mais c'est mon avis, je trouve l'organisation générale des sites spip arnachique.
J'arrive jamais à me retrouver dans les rubriques, la logique de navigation est hasardeuse ... Je suis consciens que spip permet sans doute de faire des sites bien organisés pour peu qu'on y passe le temps, et que ce probleme est sans doute grandement du aux webmestres, mais j'ai pas encore vu d'exemples qui se sont conciliés à mon gout.
Au contraire, apparamment les sites spip utilisent tous à peu près la meme désorganisation, ce qui me laisse penser (peut etre à tord) qu'il est impossible de creer autre chose qu'un site bazard, ou trouver autre chose que sur la page principale releve de l'exploit. Les bons exemples, je ne les ai peut etre tout simplement pas identifié comme des sites spip.
Le simple fait de me dire que je vais devoir passer encore des heures à apprendre à developper un langage supplémentaire au dessus du php pour finalement arrivé à un resultat qui ne me satisfera pas me repousse.
Finalement, je me suis penché sur le cas ez3. L'interface du site générale est moderne et sobre, le module d admin assez élaboré...
Mais j'ai vite déchanté en voyant les performances plus que douteuses de cette application en local (+ de 3 secondes pour m'afficher une page sur un xp2600), sans parler d'une application sous licence dual gpl qui arbore un démo version dans le coin en haut à droite...
Mon probleme reste insoluble jusqu'a maintenant. J'en arrive à mes questions:
Est ce que templeet conviendra à ce que je cherche, c'est à dire développer un site performant, avec une bonne navigation, un module d'admin rapidement sans me lancer dans un langage abscons ?
Est ce qu'il existe un cms libre , sobre, performant, avec une navigation organisée et logique, un module d'administration complet, voir une boutique ?
Je dois juste fournir à un client, un site clef en main qui lui permette de publier ses articles, vanter ses produits etc [..] sans perdre de temps sur le projet.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Sébastien Munch . Évalué à 2.
Euh ... Zope + CMF + Plone (ou alors équivalent, je ne connais que très peu les CMS sous Zope) ?
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Pierre Tramo (site web personnel) . Évalué à 7.
Tout vu que c'est un langage de template, pas plus.
> Au départ, je pensais que Templeet était un cms comme spip, il n'en est rien, c'est un langage de développement.
Il faut que tu prene le module linuxfr qui doit traimer quelques part sur le cvs ou
pomper ce qui est dans http://linuxfr.org/template/(...)
> Je dois juste fournir à un client, un site clef en main qui lui permette de publier ses articles, vanter ses produits etc [..] sans perdre de temps sur le projet.
Si tu dois aussi penser à celui qui doit le maintenir, tu ne prendras jamais templeet
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Pierre-Yves Dubreucq . Évalué à 2.
En tous cas merci pour cette étude, forte instructive ;)<ii
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par dinomasque . Évalué à 2.
La syntaxe est très facile à apprendre et permet de faire tout ce que l'on veut.
Le squelette par défaut est parfaitement dégueulasse, forcément si on s'arrête à lui ...
Va donc voir du coté de http://www.stars-oubliees.com(...) pour constater les prouesses rendues possibles par SPIP.
BeOS le faisait il y a 20 ans !
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par wikiclub . Évalué à 2.
Je le connais bien maintenant et je t'assure que celui-ci te permet de réaliser un site nikel avec une arborescence propre et logique.
Par exemple, je me demande si le site http://openweb.eu.org/(...) ne tourne pas sous SPIP.
"Update :Heu, j'ai regardé, en fait non, ils utilisent http://www.cafelog.com/,(...) dommage, ils perdent en performance ..."
En tout cas, si ce n'est pas le cas, c'est complètement possible de reproduire celui-ci au pixel près avec la même logique de navigation.
Pour cela, il faut utiliser la mise en rubrique des articles et SURTOUT les mots clés spip qui te permettrons de faire ce que tu veux, comme la double entrée "Thèmes" et "Décideur, débutant ...."
D'ailleur, je n'ai pas enore pris le temps de contacter les responsables de http://openweb.eu.org/,(...) mais je trouve qu'il serait génial d'offrir OpenWeb en squelettes SPIP, site BEAU (!!!) et conforme au XHTML strict.
Si il y a des volontaires .....
Par contre, je ne saurais me prononcer sur les performances de SPIP.
ALors, essaye à nouveau SPIP et lit le tutoriel avancé ici : http://www.uzine.net/rubrique154.html(...)
Bon courage
Romain
Par contre, il n'y a pas (encore) de module boutique
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Pooly (site web personnel) . Évalué à 1.
Si avoir des URL comme ça: http://www.onetrip.net/html/article37.html(...)
c'est vrai que c'est plus clair que : http://www.w-fenec.org/metal/sepultura.html(...)
C'est toi qui voit.
Bon, après chacun son avis...
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Code34 (site web personnel) . Évalué à 1.
Je viens de trouver des documents sur le site officiel que je n'avais pas vu, et spip pourrait tout à fait correspondre à ce que je cherche.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Julien Duponchelle (site web personnel) . Évalué à 1.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Pooly (site web personnel) . Évalué à 1.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Julien Duponchelle (site web personnel) . Évalué à 1.
# Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Pooly (site web personnel) . Évalué à 2.
Parceque sinon SPIP et daCode, même combat... Ca aurait été interessant de mesurer leur performances.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Jul (site web personnel) . Évalué à 2.
Par exemple sur libroscope nous utilisons SPIP, hors effet linuxfr nous tournons à 30 visteurs différents par jour nous sommes donc dans un cas ou le choix d'un serveur plus rapide est pertinent.
Et perso, je suis peu intéressé par le nombre de lecteur que nous pouvons avoir mais plus par ce que nous essayons de construire. Honnêtement avoir à générer plus de 10 connections secondes c'est bon pour un slashdot ou un linuxfr, mais pour 80% des cas c'est un peu inutile. Et les facilité d'édition offertes par SPIP sont plus cruciales pour moi que la vitesse de réponse à charge "élevée".
L'important pour moi c'est peut être ridicule mais dans beaucoup cas pour un site web c'est de générer et gérer le contenu.
C'est un bench intéressant malgre tout : on y apprend que pour 99% des utilisateurs de systèmes de publications la technologie n'est pas un frein. Moi ça me convient.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 1.
Raisonnement habituel, et pourtant très stupide, malheureusement. En effet pouvoir gérer 10 connections/secondes ça veut aussi dire que pour les 30 pelerins par jour qui viennent sur ton site, les pages s'afficheront beaucoup plus rapidement. Quoi de plus chiant qu'un site dont les pages sont lentes, alors qu'un site dont les pages sont instantannées, quel bonheur!
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par atlexx . Évalué à 2.
dans la mesure ou lees ressources humaines ne sont pas infinies, il n'est pas idiot, dans la limite du raisonnable, de privilegier le contenu par rapport a la qualité technique.
bien entendu, il faut que l'acces au contenu offre un certain confort, mais je ne crois pas que ce soit l'essenciel.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par jeanmarc . Évalué à 1.
Tout à fait d'accord! Vu la main mise du commerce sur le net, quand on tombe sur un site avec un contenu intéressant, on prend le temps de le lire, rapide ou pas.
bien entendu, il faut que l'acces au contenu offre un certain confort, mais je ne crois pas que ce soit l'essenciel.
Encore d'accord :-) A quoi ça sert de bouriner comme un dingue quand l'internaute navigue avec un pauvre 33.6? Il ne faut pas oublier que tout le monde ne posséde pas un tuyau gigantesque vers le net. Beaucoup de gens naviquent toujours par modem vous savez... D'autres n'ont pas internet à la maison et navique à 30 sur un netissimo1 au boulot :-)
Résultat des courses: d'abord un contenu intéressant et si le site est aussi rapide, c'est du bonus.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Jul (site web personnel) . Évalué à 1.
Je suis aussi content de constater que pour des besoins représentant 80% des cas de figures *toutes* les solutions libres testées sont acceptables. Ce qui veut dire que l'on peut se concentrer sur la façon de gérer le contenu plus que sur l'outil.
Fabien, ne penses tu pas que la chose la plus chouette qu'offre le libre aux personnes voulant d'exprimer sur internet, c'est le choix des outils sans se prendre la tête ?
PS entre nous j'aime bien templeet.
PPS chouette publicité pour openBrick. Ils ont testé des logiciels de spam avec ? ça pourrait être sympa comme ça pour leur prochaine campagne ils auront déjà le matos pour la faire eux même.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Antoine . Évalué à 1.
[^] # Impasse sur daCode ?
Posté par Rafael Pinilla . Évalué à 2.
J'ai une install de daCode qui tourne (avec la même page que celle servie par TemplEEt (la base MySQL de référence vient de là même), mais je suis infoutu de tout paramétrer pour que le cache de _pages_ fonctionne. Le cache de boxes fonctionne, mais pas les pages de base. J'ai fouillé tout ce que j'ai pu, je n'y suis pas parvenu. Je lache pas l'affaire pour autant. Je placerai une mise à jour avec drupal dès que possible.
Donc, daCode sans cache, c'est de l'interprété de base, et c'est donc lent.
daCode utilise les fonctionalités objet de PHP, et ça c'est lent. Propre, mais leeeeeeennnnnt.
Rafael Pinilla
[^] # Re: Impasse sur daCode ?
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 0.
[^] # Re: Impasse sur daCode ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 1.
bon j'ai du code à optimiser moi, alors ->[]
[^] # Re: Impasse sur daCode ?
Posté par Erwan . Évalué à 1.
C'est ptet aussi que les developpeurs ont appris en faisant DaCode, et avec ces connaissances ils ont pu faire mieux...
A noter qu'il ne faut pas comparer DaCode a templeet mais au module linuxfr de templeet, ce qui est bien different.
[^] # Re: Impasse sur daCode ?
Posté par Pooly (site web personnel) . Évalué à 1.
Après, les performanaces doivent accélérer de manière significatives :)
L'approche objet, c'est lent, moi je pense qu'il faut voir et que ca dépend du nombre d'object chargé et de l'utilité des variables initialisé à la construction :)
# Attetion au piège!
Posté par _PinG _ . É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...
[^] # Euh...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Mais quel est l'interret du "daemon pour vider le cache selon divers critères" ? Pourquoi l'application ne peut pas se rendre compte que telles pages en cache vient d'être modifié par une entrée du système et doit être regénérer (ou simplement effacé du cache) ?
"La première sécurité est la liberté"
[^] # Re: Euh...
Posté par Olivier Jeannet . Évalué à 1.
Je comprends ta remarque (on invalide une page en cache quand elle est modifiée, la logique est simple), mais comment fais-tu si ton cache a une capacité limitée ? Genre 500 Mo sur le disque, donc dès que ça arrive à 490 Mo tu vires les 10 Mo les plus vieux (ou autre algo).
[^] # Re: Euh...
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
SPIP mets des dates sur ses pages en cache. Genre une page à une durée de vie de 1h donc toutes les heures, la pages est effacé et regénéré mais cela se fait à la lecture et non à l'écriture. En plus, le site à toujours une latence d'une heure (c'est pas top notament pour les testes à moins de purger le cache à chaque fois). Pourquoi est-ce qu'il ne détruise pas la/les pages en cache lors de la mise à jour ?
"La première sécurité est la liberté"
[^] # Re: Euh...
Posté par Yann Cochard (site web personnel) . Évalué à 1.
Ce n'est pas ce qui est fait ?
Ca m'etonne car c'est vraiment ce qui semble evident. Par exemple sur mon site, il y a une encyclopedie avec des fiches sur les plantes, que les auteurs peuvent modifier. Les donnees sont classiquement stockees dans un base MySQL. Lors d'une requete, si le fichier de cache n'existe pas, il est genere, puis charge. Sinon il est juste charge.
Si un auteur modifie une fiche et donc les donnees stockees dans la base MySQL, le fichier de cache correspondant est efface. Il sera regenere lors de la prochaine visualisation de la fiche.
C'est bien ca que tu voulais dire ?
Yann.
[^] # Re: Euh...
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Si tu n'as pas de problème de place, c'est ça. Comme tu n'as pas de problème de place, tu peux aussi générer la page au lieu de juste l'effacer. Ainsi, tu peux faire pointer ton site sur du pure HTML static et avoir les performances de templeet.
"La première sécurité est la liberté"
[^] # Re: Euh...
Posté par _PinG _ . Évalué à 1.
*/ Je comprendrais jamais pourquoi l'invalidation du cache n'est pas relier à la modification des données qu'il contient : C'est le cas de certains systèmes de cache (templeet par exemple, mais aussi mon système de cache dont je parles dans le post précédent...). Mais certaines données sont volatiles dans la durée, ou selon d'autres critères (nombre d'affichages, ...), c'est le cas -par exemple-d'une page d'accueil de news qui ne présente que les news du jour (Ce que l'on apelle "a la une" ou "édition quotidienne"). De plus, dans certains cas (particuliers), le déploiement du cache est indépendant du code du site, auquel tu n'as pas toujours accès, ou que tu n'as pas forcément le droit/l'envie de modifier... Dans ce cas, c'est le lifetime de la page qui sert à remetre à jour le cache... Un autre concept auquel il faut pensser est la publicité... Si tu dépends d'une régie un peut chiante, tu doit parfois renouveler par toi meme le cache régulièrement (problèmes d'autopromo, de remplissage, de script de pub mal foutu, ...).
*/ Mais quel est l'interret du "daemon pour vider le cache selon divers critères" ? : Je pensse que tu n'as pas compris le fonctionnement de cette nouvelle génération de systèmes de cache. Le client est dirigé automatiquement vers la page statique en cache sans aucune intervention d'aucun script (seul mod_rewrite selon les cas entre en jeu) qui bouferais des ressources à tout casser. Si le serveur ne peut fournir cette page, alors il doit renvoyer une erreur 404. C'est là que toi, tu remplaces l'erreur 404 par ton script ou ton cgi qui vas générer la page dans le cache (le cas échéant, cad si vraiement elle existe hein, sinon il renvoie vraiement un 404) et la renvoyer au client. Donc si le fichier existe dans le cache, meme si il est expiré (parceque certaines contraites te forcent à mettre un délai de vie à certaines pages), comme aucune requète client ne vas déclencher d'execution de script pour cette page, elle ne sera jammais renouvelée. D'où le daemon, ou le script lancé régulièrement par cron (ce qui reviens au meme ;)), qui permet de faire le ménage dans le cache... Ca permet aussi de gérer certains critères bien lourds comme des problèmes d'espace disque... Oui on est sur un serveur, donc oui on met en face les ressources qu'il faut, mais si -pour je ne sait quelle raison- un client veut son cache en tmpfs (mémoire vive), bah 2Go en mémoire vive, ca fait mal :/
*/ pour le problème de savoir si le cache doit etre regénéré au fur et à mesure ou il est invalidé, ou si on efface simplement le ficheir du cache, c'est très complexe... En effet, si tu efface, le premier client qui redemanderas la page se veras servir de facon plus lente que d'habitude (attention, tout est relatif, cad que dans le pire des cas, ca ne seras pas plus lent qu'une page dynamique standart), par contre, pour les pages peut demandées, ca permet d'économiser du disque et de la charge... Par exemple, pour le gros site dont je parlais, le cache représente 4.1Go de html (bon, c'est vrai que certaines pages sont lourdes en HTML parceque mal faites, mais bon, je gère pas les squeletes moi...) pour 210000 pages en cache environ... D'un autre coté si tu le génères en bg, tu t'exposes au fait de générer des pages qui ne seront pas consultées, ou du moins pas avant quelques temps... Donc tu boufes du CPU et du HDD pour rien...
[^] # Re: Euh...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
2)3) J'ai très bien compris l'utilisation du 404, merci :) (depuis le RMLL d'ailleurs).
En fait tu as plusieurs cas que j'ai un peu mélangé.
Le cas du web dynamique par "confort" : typiquement SPIP. Le coté dynamique permet une mise à jour facile. Le coté lecture pourrait être 100% static car les pages sont peu nombreuses (ou au moins la première page du site, la plus consulté).
Il y a le cas du contenu/visualisation très dynamique type linuxfr (ou ton site ?) où il existe des pages différentes pour chaque client. Là, la génération ne peut pas être exaustif (trop de page, une modification entraine la modification de 100 pages, etc...) alors le traitement avec le 404 est bien adapté.
Et le dernier cas : plus de modif que de visualisation : aucun interret de faire le boulot à l'avance.
Tout ce qui est problème de taille de cache, peut se régler en cron ou lors de la génération des pages (cron ne te garantit pas que tu va pas péter le quota disque entre 2 lancements).
(au fait, il parait que la couche disque de linux est tellement performante que l'on ne gagne quasiement rien à utiliser tmpfs)
"La première sécurité est la liberté"
[^] # Re: Euh...
Posté par _PinG _ . Évalué à 1.
*/ sinon oui, le site dont je parles est comparable avec Linuxfr sur le fait qu'il est hautement dynamique, mais aussi sur le fait qu'il a une grosse DB de données antérieures (que les clients peuvent rapeller), qu'il a beaucoup de hits (plus de 2* plus que LinuxFR à prioris), et qu'il a des affiliés (dont des gros noms) qui affichent le même contenu mais avec leur propre 'skin', et ce depuis ce serveur...
*/ pour la taille du cache, personellement j'avais penssé (si le problème se présentait) à un daemon qui surveille la création de fichiers dans le répertoire grace à imon/fam/cequetuveux... C'est un peut lourd, puissequ'il vérifie à chaque fois qu'un fichier est créé dans le répertoire du cache, mais au moins, tu peut pas te faire rouler, et tu gères bien ;)
*/ VFS/FS : C'est vrai que la lecture est très performante sous linux (surtout sur un serveur, qui a du raid, ou du SCSI, ou au moins du bon IDE optimisé avec hdparm), mais franchement, tu peux pas me faire croire que la lecture (ou pire : l'écriture) est aussi rapide sur un HDD que dans la ram. Le paliatif que j'ai trouvé, c'est de foutre le cache de ce site sur une partoche reiserfs, où la lecture est très rapide, et où la quantitée de fichiers dans le répertoire n'est pas un obstacle... Et je sent très clairement des différences de perfs entre ext2/3 et reiser...
[^] # Re: Euh...
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
En fait, le system de fichier de linux utilise un max de cache en RAM d'où le très faible gain en vitesse avec tmpfs. Il existe même un patch de linux qui vire le timout d'écriture sur disque (il flush ses caches en 3 secondes au maxi sauf si il y a un sync évidement), cela permet de mieux dormir à certaine personne car le HD finit par s'éteindre. Et tu as de fait, l'équivalent d'un tmpfs.
Reiser va (beaucoup) plus vite que ext sur les "petits" fichiers, sans doute que tes fichiers html rentre dans cette catégorie.
"La première sécurité est la liberté"
[^] # Re: Euh...
Posté par _PinG _ . Évalué à 1.
# Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Benjamin (site web personnel) . Évalué à 2.
Et pour les autres c'est ON ?
Si c'est le cas, tu prends tout ton benchmark, tu prends la poubelle d'à-côté, et tu jette l'un dans l'autre ;)
...
une requete DNS par page vue ca peut très lourdement perturber notre ami apache, et ca a un impact non négligeable sur les performances...
surtout si tu as testé en local et que ton ip de client ne se résolvait pas...
...
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Anonyme . Évalué à 1.
( http://httpd.apache.org/docs/misc/perf-tuning.html(...) )
Ceci dit, même si c'était on, si l'on compare les differents systèmes tels qu'ils fonctionnent par défaut, le bench est toujours valable. Mais à nuancer puisqu'on pourrait mettre en avant le fait que les confs des autres ne sont pas optimisées.
[^] # HostNameLookup Off
Posté par Rafael Pinilla . Évalué à 1.
Juste pour info, voici ce que m'a affiché le footer du thread.
**************************************************************************
Cette page a été générée par Templeet en 15.5268s (dont 1.7378 de SQL). (Voir le source du template)
Cette page est peut-être conforme xhtml 1.0.
**************************************************************************
Comme quoi, quand la page est complexe, les requètes Mysql sont nombreuses et la génération de la page cachée plus longue ;)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.