Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick

Posté par . Modéré par Xavier Antoviaque.
Tags :
2
7
avr.
2003
Internet
Pour mettre en place un serveur Web à vocation médicale sur un OpenBrick dédié dont la puissance est limitée, j'ai testé la réaction sous forte charge de Apache, Zope, SPIP et Templeet.

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.
  • # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick

    Posté par . Évalué à 4.

    Wouah templeet est tellement balaise qu'il est même plus rapide qu'apache :)http://nexus.ouvaton.org/Benchmark_OpenBrick/EssaiArticle_html_m379(...)

    Non bon ok c'est pas drôle !
    • [^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick

      Posté par (page perso) . Évalué à -2.

      Bah les benchs ça vaut ce que ça vaut hein, mais bon ça montre un ordre de grandeur.
      • [^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick

        Posté par (page perso) . Évalué à 10.

        Si on est authentifié ça donne la meme chose comme résultat ? Car il me semble qu'il y a une partie dynamique et le moindre truc dynamique fait généralement chuter les perfs... La redirection de 404 ne marche pas dans ces conditions (peut-être que je me trompe et qu'il y a un module apache qui permet de le faire ?).
        • [^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick

          Posté par . Évalué à 10.

          Et bien non.
          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 . Évalué à 10.

            Note à ceux qui poussent des cris. Je ne compare pas Zope, Templeet etc. Je les mes en ligne pour un test de charge, sans plus.
            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: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick

            Posté par (page perso) . Évalué à 4.

            Quelqu'un a-t-il fait des test lorsque le DocumentRoot ne pointe pas directement sur le cache de Templeet ?
            • [^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick

              Posté par . Évalué à 6.

              Oui, moi, quand, comme un crétin, je n'avais pas suivi la doc de templeet.
              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.
          • [^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick

            Posté par (page perso) . Évalué à 10.

            Je parlais de la page de linuxfr sur laquelle, par exemple, les atuces qui changent à chaque requêtes et la boite de login avec les XP's qui sont variables. Cette partie dynamique n'est pas vraiment cacheable me semble t'il ?
          • [^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick

            Posté par . Évalué à 2.

            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.

            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 (page perso) . Évalué à 10.

    Je pense que ce bench est pas mal, mais, il ne prouve rien, à part que templeet "c'est bien car ça cache sans avoir a rajouter un proxy avant", ce qui est un peu injuste par rapport aux autres.

    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.
    • [^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick

      Posté par (page perso) . Évalué à 1.

      Tout est basé sur la redirection de 404 d'apache. Cfr . http://hotwired.lycos.com/webmonkey/02/26/index4a_page4.html?tw=pro(...) (désolAY pour le coldfusion mais j'ai trouvé le lien quand on m'a demandé de tuner un web écrit en CF).
      • [^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick

        Posté par (page perso) . Évalué à 10.

        REMARQUE : Il se pourrait que les autres solutions se rapprochent fortement de templeet si on leur greffe une toute petite extension effectuant une redirection de 404 (page cachée absente) vers une générateur de page qui fait appel à génération de la page de cache et puis l'affiche. Les pages cachées pouvant être nettoyées par un script cron qui retire les pages considérées comme trop vielles.

        La redirection de 404 est une méthode très simple à mettre en oeuvre et qui fait gagner beaucoup. Le supporter de manière native comme templeet est un avantage en plus.
        • [^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick

          Posté par (page perso) . Évalué à 7.

          Surtout que templeet ne serait vraiment pas difficile a battre, le temp de parsing d'un template est vraiment faramineux.
          • [^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick

            Posté par . Évalué à 1.

            Attention, un troll semble se dissimuler dans ce post ....
            • [^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick

              Posté par (page perso) . Évalué à 1.

              Meme pas, fait des tests, un site avec templeet sera toujours plus lent qu'un site en php vu qu'il y a un parsing hyper lent en plus.

              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.
              • [^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick

                Posté par (page perso) . Évalué à 1.

                J'ai pas vraiment regardé le code templeet. Mais il est probalble que celui ci refasse le parsing à chaque fois qu'une ligne est exécutée même si celle-ci a déja été exécutée. Php fait surement un truc du genre : code php --parsing--> code intermédiaire --machine virtuelle--> résultat de l'exécution. Ce qui expliquerait la différence de temps d'exécution
              • [^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick

                Posté par (page perso) . Évalué à 3.

                Remarque, comme les journaux ne sont pas modérés, à priori tu pourrais quand même le diffusé. en tous cas, je suis interessé !
              • [^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick

                Posté par (page perso) . Évalué à 2.

                Templeet compense sa lenteur par un systeme de cache mais si tu en fait un en php, templeet n'a plus aucun avantage.

                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 . Évalué à 4.

                Je ne joue pas à l'El33t, je mets des A ou EE maj pour ne pas s'eméler les pinceaux entre templAte et templEEt.

                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 (page perso) . Évalué à 3.

                  Pas exactement.

                  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 . Évalué à 2.

      slashcode peut en effet étre un bon competiteur, mais j'ai peure qu'ils soit plus a dans son element, avec un infrastructure plus lourde... de mémoire il integre lui aussi un systéme de cache attypique, mais aussi des contreinte temporel ou de charge, pour la mise a jour de certeinnes pages de cache ou autre.

      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 (page perso) . Évalué à 3.

    Les graphiques traitant du passage de linuxfr.org à templeet (partie en PS) m'ont tout de suite attiré, domage que l'on tombe en 404 en suivant les liens....
    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 (page perso) . Évalué à 10.

    Zope possède un système de cache des objets qui permet de diminuer la charge et de supporter la montée en charge des demandes.
    Vous devriez y jeter un oeil et refaire des benchmarks.
    • [^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick

      Posté par . Évalué à 8.

      Ouf, je ne suis pas le seul à être étonné par les données de ce benchmark.

      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 . Évalué à 5.

        Si tu maîtrises assez Zope pour m'aider à le paramétrer à son avantage, je prends. Je me suis contenté de vérifier l'activation du cache ainsi que sa taille, qui m'a semblé correcte.

        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 . Évalué à 1.

          Si tu maîtrises assez Zope pour m'aider à le paramétrer à son avantage, je prends. Je me suis contenté de vérifier l'activation du cache ainsi que sa taille, qui m'a semblé correcte.

          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 (page perso) . Évalué à 1.

            Pourquoi mets-tu un deuxième cache ? Tu utilises déjà le cache de Zope. Si tu mets en cache (HTTP cache et RAM cache) tes objets correctement, tu n'as pas besoin d'Apache.
            • [^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick

              Posté par . Évalué à 4.

              Un "RAM Cache" permet d'éviter la génération de certaines parties de documents dans Zope. Par exemple, sur LinuxFR, l'entête des pages est statique (ou presque, y'a quand même la date), mais il est quand même souhaitable de gérer les listes de liens autrement qu'à la main dans le code HTML... dans ce cas, on crée un document chargé de faire le rendu de cette partie de la page et on l'associe à un "RAM Cache" chargé de garder la page générée pendant x secondes (ce n'est qu'un exemple très très simpliste).

              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 (page perso) . Évalué à 1.

                Je pense que c'est plus prévu pour les caches du coté des clients. Dans une grande majorité des cas (AMHA) les gens qui se connectent à internet passent par un proxy, que ce soit le proxy de leur fournisseur d'accès (quel FAI ne propose pas de proxy, quand ce n'est pas un cluster de proxy comme chez AOL :-) ou celui de leur société.
                • [^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick

                  Posté par . Évalué à 2.

                  Je pense que c'est plus prévu pour les caches du coté des clients.

                  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 . Évalué à 5.

        Oui, surtout que l'on met rarement (voire jamais) Zope en frontal direct. Zope n'est pas fait pour cela (sans vouloir troller ;-).

        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 (page perso) . Évalué à 8.

          surtout que l'on met rarement (voire jamais) Zope en frontal direct.

          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 . Évalué à 2.

            Je dois avouer que j'ai vu beaucoup de cas où Zope était en frontal...

            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 (page perso) . Évalué à 0.

          > Oui, surtout que l'on met rarement (voire jamais) Zope en frontal direct.

          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 . Évalué à 1.

            Oui pour tout (sauf pour les clients ;-)

            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 (page perso) . Évalué à 1.

              En dehors de ce petit FUD, je dois dire que ce que tu dis correspond à *tous* les logiciels fonctionnant de manière dynamique.

              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 . Évalué à 1.

                FUD .. non non !!
                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 (page perso) . Évalué à 1.

                  Concernant cette référence, je suis tout à fait d'accord:
                  "[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 . Évalué à 1.

                    > Unfortunately, AFAIK the current SSL support for ZServer leaks memory
                    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 (page perso) . Évalué à 2.

                  > Je m'abreuve aux meilleures sources (shane@zope.org)
                  > 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 . Évalué à 1.

        Chaque document fait 18.2 Ko. Quelle qu'en soit la provenance
        C'est à un pouillème la même taille.

        Vérifies.
  • # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick

    Posté par (page perso) . Évalué à 7.

    Pour être un utilisateur fréquent d'un portail sous Zope (http://www.univ-savoie.fr/Portail(...) pour ne pas le citer), ces résultats ne m'étonnent pas trop, Zope est un peu lourd sur les bords. (combien de fois j'ai entendu "p..... de portail qui rame !")
    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 (page perso) . Évalué à 5.

      Par contre tu en as pour un moment à refaire ce portail en Templeet. Mais pour linuxfr Templeet ca va tip top.
      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 . Évalué à 10.

        J'avais mal lu le texte du bench. Tu veux mettre en place un CMS !

        <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 (page perso) . Évalué à 3.

          beaucoup plus adapté a un site ou tout est computé a la volée (pour du CMS justement) ;-)

          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 . Évalué à 1.

            Je n'ai pas du etre clair ;-)

            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 . Évalué à 4.

              Bof, ca doit dependre du CMS. Il faudrait regarder la distribution des documents consultes, des etats des documents... Un meme document dans un meme etat (workflow) peut tres bien etre consulte par 50 personnes ayant les meme droits ! Pourquoi generer plusieurs fois la page ?

              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 . Évalué à 2.

                Oui. Oui. On parle bien de la meme chose !

                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 (page perso) . Évalué à 9.

    Je pense que ce bench prouve une et une seule chose: Comme toujours en info, une cache ça accélère beaucoup les choses!

    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 (page perso) . Évalué à 10.

    Si je peux me permettre c'est n'importe quoi ce benchmark.

    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 (page perso) . Évalué à -4.

      Et la marmotte elle ferait les requettes de ping pong...
    • [^] # Re: Portnawack

      Posté par (page perso) . Évalué à 4.

      Pour info, j'avais commencé une version Python de Templeet cet été. J'ai depuis laissé tombé faute de temps, mais si un repreneur veut s'en mêler... :-)
    • [^] # Re: Portnawack

      Posté par . Évalué à 3.

      pour certaines applications, des produits a priori complémentaires se recouvrent dans leur fonctionnalités, de ce fait, il n'est pas si absurde de les comparer: par exemple, tomcat4 peut tres bien servir des pages web tout seul , et dans lla doc, il est en gros indiqué qu'il n'y a qu'une bonne methode pour savoir si on utilise tomcat ou apache+tomcat, c'est de tester ...
      • [^] # Re: Portnawack

        Posté par (page perso) . Évalué à 3.

        Enfin bon, de la a comparer Apache a SPIP, sachant que SPIP ne peut pas se passer d'un serveur web, c'est tres fort !

        Et pourquoi ne pas comparer les performances de Linux avec celles du Pentium 4 ?
        • [^] # Re: Portnawack

          Posté par . Évalué à -1.

          Je pense que l'analogie c'est plutôt comparer un langage de programmation avec du code assembleur. Ce qui n'est pas con du tout. En tout cas moins que le commentaire consensuel débile "ces softs sont complémentaires, il faut pas les mettre en opposition".
    • [^] # Re: Portnawack

      Posté par . Évalué à 0.

      Disons que SPIP n'ayant pas de contenu tellement dynamique, il devrait directement attaqué du HTML statique et les pages modifiant du contenu modifient ces pages. Même pas besoin du truc de l'erreur 404.

      "La première sécurité est la liberté"

  • # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick

    Posté par . Évalué à 1.

    "Je pourrais effectuer des mesures équivalentes avec d'autres CMS comme *Nuke ou Drupal, cependant, comme je n'en connais aucun utilisant le même système de gestion du cache que celui à la base du concept de Templeet, je n'essaie même pas."

    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 . Évalué à 10.

    Salut,

    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 (page perso) . Évalué à 3.

      néanmoins SPIP assure deux millions de pages par mois pour le Monde Diplomatique, ce qui n'est pas rien non plus

      Pour mon information, sur quelle machine, et avec quel type de charge ? C'est important quand même :)
      • [^] # Type de machine ?

        Posté par . Évalué à 1.

        Type de machine ? A 2 Millions de pages/mois, ça fait du 0,7 page/sec. Ca tiendrait sur un OpenBrick :) (3.5p/s)
        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 . Évalué à 2.

        La machine est un bi-processeur à 1 GHz avec 2 Go de mémoire. La charge est de l'ordre de 0,5 en moyenne (elle oscille grosso modo entre 0 et et 1,5), mais ce n'est pas très pertinent car d'autres bidules sont hébergés dessus (sites Web, mailing-listes). D'autre part le système de statistiques de SPIP est activé, qui bouffe un peu de ressources (connexion systématique à MySQL).

        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 . Évalué à 1.

        Pour mon information, sur quelle machine, et avec quel type de charge ? C'est important quand même :)

        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 (page perso) . Évalué à 2.

      l'utilisation d'une plateforme légère ne me semble pas pertinente [...] il vaut mieux une machine mutualisée puissante servant N sites plutôt que N machines dédiées faiblardes servant chacune un site.

      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 . Évalué à 7.

    Au niveau technique templeet semble tres bien. Par contre, sans vouloir faire de trop gros troll, personnellement je trouve la syntaxe de Templeet vraiment affreuse. A ce tarif la, autant ecrire des fonctions directement en PHP :)

    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 (page perso) . Évalué à 10.

    Lut,

    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 (page perso) . Évalué à 2.

    Ma grande question c'est quand même, pourquoi le benchmarke a-t-il fait l'impasse sur daCode... ???
    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 (page perso) . Évalué à 2.

      ouaip, même si je savais que spip était plus lent, je l'utiliserais toujours : ce qui est important pour un outil c'est l'utilisation que l'on en fait, et l'utilisation raisonnable de ressource par l'outil.
      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 (page perso) . Évalué à 1.

        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.

        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 . Évalué à 2.

          il reste quand même que la qualité d'un site est avant tout son contenu...
          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 . Évalué à 1.

            il reste quand même que la qualité d'un site est avant tout son contenu...

            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 (page perso) . Évalué à 1.

          Honnêtement, j'aime bien la diversité, et je pense juste que templeet est un outil adapté a une certaine façon de concevoir la gestion du contenu, SPIP à une autre.

          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 . Évalué à 1.

            Au fait, enrober SPIP dans templeet juste pour profiter du cache ne doit pas être trop dure. Il faudrait "juste" faire une translation d'url. Genre cache static par defaut et redirection sur le moteur SPIP quand la page n'existe pas (et destruction du cache templeet lors de modif, de toute façon cela ne peut pas ralentir l'application).

            "La première sécurité est la liberté"

            • [^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick

              Posté par . Évalué à 1.

              Non, ce n'est pas possible, enfin pas entièrement. SPIP fait un tas de traitements y compris quand une page est dans le cache, pour diverses fonctionnalités (syndication, indexation, newsletter...). De plus il y a un système d'inclusion impliquant l'utilisation de PHP dans les pages cachées. Bref à moins de se priver volontairement d'un certain nombre de fonctionnalités ou d'utiliser des ruses de sioux spécifiques à une structure de site particulière (comme le fait probablement linuxfr avec templeet), un site SPIP ne peut pas être transformé en pages entièrement statiques.
    • [^] # Impasse sur daCode ?

      Posté par . Évalué à 2.

      Et bien c'est simple.
      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 (page perso) . Évalué à 0.

        Propre, l'objet, bof... Je trouve que le côté modulaire de Templeet est 100 fois plus propre que celui de daCode. Mébon...
        • [^] # Re: Impasse sur daCode ?

          Posté par (page perso) . Évalué à 1.

          C'est parce que les développeurs originels de daCode sont plus mauvais que les développeurs originels de Templeet... hmm mais y a le même nom dans les deux... [/troll]

          bon j'ai du code à optimiser moi, alors ->[]
          • [^] # Re: Impasse sur daCode ?

            Posté par (page perso) . Évalué à 1.

            C'est parce que les développeurs originels de daCode sont plus mauvais que les développeurs originels de Templeet... hmm mais y a le même nom dans les deux...

            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 (page perso) . Évalué à 1.

        Cela dit, il est possible de passer par le cache de page daCode de tel manière à faire servir des pages statiques directement par apache. Les pages etant stocké dans cachehtml/ par exemple, il suffit de le remonter d'un niveau et de modifier la classe Cache.
        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 . Évalué à 4.

    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...
    • [^] # Euh...

      Posté par . Évalué à 2.

      Je comprendrais jamais pourquoi l'invalidation du cache n'est pas relier à la modification des données qu'il contient.

      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 . Évalué à 1.

        Mais quel est l'interet 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) ?

        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 . Évalué à 1.

          Evidement, si tu as un problème de place, tu fais du LRU (comme n'importe quel cache). Mais cela ne suffit pas du tout pour assurer la cohérence du cache. Ce "ménage" peut être fait lors de la génération de page (hors cache donc).

          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 (page perso) . Évalué à 1.

            Pourquoi est-ce qu'il ne détruise pas la/les pages en cache lors de la mise à jour ?

            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 . Évalué à 1.

              oui.

              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 . Évalué à 1.

        Alors, je vais répondre à tes questions aussi clairement que possible :

        */ 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 . Évalué à 2.

          1) dans ton entrée du système, tu as donc en plus la date du jour ou des compteurs internes à l'application.

          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 . Évalué à 1.

            */ ouep, tu gères certaines choses qui vont modifier le contenu (ou le contenant ;) ) des pages, donc il faudra regénérer le cache si ces choses bougent... Personellement, je stoque certaines choses concernant les pages en cache dans une table de hachage stoquée sur le disque (come j'ai la chance de travailler en perl, j'utilise des dbm*), je met à jour les infos à chaque fois qu'une page est générée, et le daemon lit dedans pour décider quoi faire... Mais j'ai aussi certaines actions (quand on rajoute/modifie un enrengistrement dans certaines tables) qui mettent à jour le cache par évènements, histoire d'optimiser un peut... Mais ca n'est pas réalisable pour tout.

            */ 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 . Évalué à 1.

              Bah, si ! :)

              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 . Évalué à 1.

                oui, surtout depuis les derniers noyeau, mais principalement pour les fichiers beaucoup utilisés... Hors ce qu'il y a d'interessant avec le tmpfs (en plus de la vitesse d'écriture), c'est la disponibilité du fichier instantanément en Ram, cad qu'un fichier qui n'est pas demandé souvent (on vas dire qui n'as pas été demandé depuis une heure pour être presque surs ;)) est quand même dispo instantanément. Exit les temps d'accès disques... Et si tu multiplies ca par 100 ou par 1000, bah ca fait la différence. De toute facon, je ne pensse pas que cache 'statique' serveur tmpfs soit nécessaire, mais bon, chacun fait ce qu'il veut ;) Sinon, reiser est plus rapide de facon générale, BEAUCOUP plus rapide sur les petits fichiers (oui, on peut dire que les pages HTML rentrent dans cette cat...), et ENORMEMENT plus rapide pour les répertoires qui ont beaucoup de fichiers (un cache HTML par exemple, surtout si il est à un seul niveau...). Et je te promet que sur le site dont je te parles, reiserFS a fait une très nette différence pour le cache... J'ai l'exemple d'un gros serveur de mail aussi qui doit son salut à reiserFS...
  • # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick

    Posté par (page perso) . Évalué à 2.

    HostnameLookups off ?

    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 (page perso) . Évalué à 1.

      Benjamin, a priori, le defaut avec apache 1.3 c 'est off

      ( 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 . Évalué à 1.

        Merci d'avoir répondu à ma place.

        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 à ceux qui les ont postés. Nous n'en sommes pas responsables.