XHTML.net

Hugo said:

C'est symfony et non Symphony ^_^

Bravo pour Pluf :) Bonne continuation dans ton travail sur ce framework léger.

Hugo.

Renaud said:

Un simple Hello World n'est absolument pas représentatif de l'utilisation normale d'un site web et, par conséquent, des performances d'un framework.

Loïc said:

Renaud: C'est tout à fait vrai et c'est bien pour cela que j'ai pris le temps de bien faire un lien vers le billet correspondant de Paul M. Jones, car il explique bien les raisons de cette approche.

Quel est l'intérêt de ce type de benchmark ? Cela permet d'évaluer facilement le coût en terme de performances du framework par rapport à un appel PHP tout simple.

C'est la méthodologie utilisée par Rasmus Lerdorf[1] et elle est très bonne pour une comparaison de la performance du "cœur" des frameworks. Cela veut dire que quelque soit les optimisations que tu feras ensuite dans ton code, tu ne pourras pas faire mieux. Cela te donne donc la ligne de base de ton framework.

Bien entendu ensuite si tu fais du SQL foireux, des accès distants SOAP sans cache, etc... le coût du framework peut devenir négligeable. Mais c'est une autre histoire.

[1]: http://talks.php.net/show/froscon08/24

Oncle Tom said:

Ça va les chevilles ? ;-)

Un framework peut être plus rapide mais ce n'est intéressant que si on recherche un développement par la performance. Je préfère avoir un framework plus consommateur de ressources et fonctionnel mais fournissant des mécanismes d'optimisation et de cache que l'inverse.

Sinon oui pour être plus performant on peut encore revenir au code from scratch ;-)

Loïc said:

> Je préfère avoir un framework plus consommateur de ressources et fonctionnel mais fournissant des mécanismes d'optimisation et de cache que l'inverse.

Cela sous entend que l'un exclut automatiquement l'autre, mais c'est faux. On peut obtenir fonctionnalités, faible consommation de ressources, le tout avec des mécanismes d'optimisation et de mise en cache.

Pluf et Solar sont de parfaits exemples car dans les deux cas, le chemin de résolution d'une requête est très bien optimisé. Ce n'est pas parce que ce chemin est optimisé que le framework n'est pas fonctionnel, c'est parce qu'il est bien conçu, tout simplement.

Laurentj said:

@oncle tom : mmm... va dire ça à des personnes qui développent des sites à très fort trafic et néanmoins avec un fonctionnel complexe, ils vont être mort de rire :-)

Quant à Symfony 1.1, j'ai lu un peu son code, c'est devenu un véritable bloatware.

@loic: tu as réèllement fait ces benchs ? non parce que c'est bizarre que tu obtiennes les mêmes résultats pour les autres frameworks que ceux de Paul....

Loïc said:

Non, je n'ai fait qu'une comparaison "baseline" PHP contre "Hello World!" le plus simple de Pluf. C'est pour cela que je ne donne pas le nombre de requêtes par secondes, car je suis à 350 avec mon laptop, je n'ai donc qu'une comparaison "relative".

Paul a mis en ligne tout le code pour lancer les tests, je regarde pour faire à mon tour les tests avec la même configuration.

Loïc said:

Je viens de lancer la comparaison en utilisant les outils de Paul, cela donne :

baseline-php 1.0000 (1332.53 req/s)
pluf-trunk 0.2582 (344.02 req/s)
solar-svn 0.1019 (135.77 req/s)

Grosso modo, Symfony est une tortue, cela ne vaut même pas la peine de comparer tellement cela fait peine à voir la différence. Un écart de 1 à 5 !

Oncle Tom said:

@laurentj & @Loïc mais qui a parlé de symfony 1.1 ?

"Symfony est une tortue" : quand on regarde le bench, si c'est la conclusion qui en est tirée, certain qu'on peut proclamer Pluf comme étant le best world ever.

Jusqu'à preuve du contraire, y'a pas de meilleur framework : chaque framework est adapté à 1 ou plusieurs situations.
Et si jamais vous cherchez un "meilleur" (puisqu'il faut un meilleur à tout), demandez plutôt aux utilisateurs/développeurs. C'est eux qui peuvent le dire. Pas vous.

Plouf pour moi.

Loïc said:

Oncle Tom : Il y a une chose que j'aime dans ces benchmarks, c'est que cela force tout le monde à regarder sous le capot. Pour obtenir ce résultat, il m'a fallu corriger un bug avec l'envoi des headers dans Pluf. Symfony et les autres vont travailler sur la performance et tout le monde va y gagner.

La performance pure du cycle de distribution des requêtes est important pour un site à fort trafic, car si on met en place un niveau de cache, par exemple memcached, on va toujours devoir passer à travers ce cycle.

Je fais de la gestion de conférences, donc quand brutalement plusieurs milliers de personnes viennent taper dans le site sur une période d'une heure, c'est très important d'avoir des pages qui répondent vite. Car plus de requêtes par seconde, cela veut aussi dire *un temps de réponse plus court* et donc une meilleure impression de fluidité dans l'utilisation du site. Ça c'est très important et ce n'est pas un cluster qui l'apportera.

Pour Pluf, je suis merveilleusement heureux de coder avec, donc c'est le meilleur pour moi, bien entendu :-)

Xavier said:

@Loïc : "Cela veut dire que quelque soit les optimisations que tu feras ensuite dans ton code, tu ne pourras pas faire mieux."

Certes mais cette "ligne de base" n'a une valeur concrète que tant que si on considère qu'un framework ne fait que recevoir une requête et retourner une réponse. je suis curieux de savoir différentes choses (et c'est pas forcément à toi que je devrais poser la question, mais plutôt à ce bon vieux baratineur de Paul M. Jones) :

* quel est le gain d'un "framework minimaliste" en terme de vitesse de développement ? Une entreprise se contrefout de payer deux serveurs au lieu d'un si, grâce à l'emploi d'un framework légèrement plus coûteux en performances mais bien plus flexible et riche en conventions, elle a pu gagner 10 ou 20% de temps de développement de son projet (à mon avis c'est plus encore).

* considérant que nous ne vivons pas dans un monde de barbares, on peut librement imaginer qu'une application Web, de nos jours, fait appel à une base de données. Remplaçons le simple "Hello World" par une série de requêtes à la base de données. Quel est alors le résultat du bench ? Qu'est-ce qui indique que les différents frameworks testés ont des comportements similaires lorsque les fonctionnalités testées sont élargies ? Ou, reformulé : en quoi un test de "Hello world" est-il extensible et passe-t-il à l'échelle ? Si ça se trouve, Pluf est une grosse merde atomique dés lors que l'on veut faire appel à la base de données (ActiveRecord) ou mettre en place un listener (ah bah non, ça n'existe pas) ?

* ces tests se font avec le cache désactivé. C'est stupide : si un framework prévoit des mécanismes de cache, c'est pour qu'ils soient mis en oeuvre ! En production, sur une appli à haute charge, on emlie toujours le système de cache s'il existe. Or, le développement de ce mécanisme de cache a imposé des contraintes architecturales qui ont des impacts sur le fonctionnement intrinsèque du framework. Effectuer des tests de performance de frameworks sans activer le cache, c'est comme comparer la vitesse d'une bicyclette et d'une Ferrari moteur éteint.


@Laurent : "Quant à Symfony 1.1, j'ai lu un peu son code, c'est devenu un véritable bloatware." : Étonnant qu'on n'ait pas entendu parler de Jelix. Vraiment étonnant.

En résumé, ce genre de "benchmarks" ne sont que des discours de poissonniers, ou de racoleurs qui souhaitent se faire mousser à coup de nanosecondes. On ne mesure pas l'efficacité d'un framework (je parle en tout cas des frameworks professionnels, pas des bricolages amateurs) au temps d'exécution d'un Hello World, mais suivant un ensemble de critères pondérables : qualité de la documentation, volume de la communauté, efficacité technique, disponibilité des compétences, sécurité, richesse fonctinnelle, outillage, etc. C'est en prenant tout cet ensemble de critères qu'on peut effectivement et concrètement mesurer la qualité d'un framework.

A lire :
* http://obvioushints.blogspot.com/2008/09/we-started-something.html : "When are we going to realize that the point of a framework is not to run as fast as assembly code, but to improve developer productivity and save money in developer time?"

* http://www.biologeek.com/2008/09/le-framework-web-le-plus-rapide-du-monde/ "Un vrai comparatif demanderait de développer plusieurs applis avec plusieurs frameworks sur plusieurs architectures avec des charges aléatoires en comparant les temps d'accès, de développement et de maintenance."

Loïc said:

Pluf est complètement modélisé sur la base de Django, *rigoureusement la même approche*. Donc, on peut en déduire que pour la vitesse de développement, c'est là. D'ailleurs la vitesse de développement de InDefero http://projects.ceondo.com le prouve parfaitement.

Pour le point 2, c'est avec plaisir que l'on peut mettre en place une méthodologie de test commune (et il existe un système d'évènements dans Pluf qui marche très bien).

Pour le point 3, s'il te faut un système de mise en cache pour afficher "Hello World!" c'est qu'il y a un problème quelque part. Les tests étaient tous effectués avec la mise en cache de Symfony pour la conversion des fichiers de configuration XML en PHP (voir les commentaires de Paul). Avec Pluf, on peut mettre en place un middleware de mise en cache sans aucun impact sur la performance si on ne l'utilise pas.

C'est du baratin que de raconter que parce qu'il y a des fonctionnalités X, Y et Z dans le framework les performances tombent, *bien conçu, on garde les performances*, la preuve, Django et Pluf.

Pour tes liens, sur le lien 1, je suis 100% d'accord avec la citation que tu prends, mais je réitère que c'est très intéressant de tester ce cas limite "Hello World!", car cela force à *regarder le chemin d'exécution minium* et donc c'est bon.

Pour le lien 2, David est venu déballer un gros sac de buzz word ici, j'ai été poli avec lui, mais à la fin, il m'a fatigué, la discussion est ici :
http://xhtml.net/scripts/InDefero-bug-tracking-git/481-InDefero-008-Liste-de-surveillance-et-amelioration-du-rendu
je vois donc ce billet comme la réponse d'une personne vexée. Bien bas...

Xavier said:

@Loïc : "Donc, on peut en déduire que pour la vitesse de développement, c'est là. D'ailleurs la vitesse de développement de InDefero http://projects.ceondo.com le prouve parfaitement. " : On ne peut rien conclure du tout, car tu es le développeur du framework ET de l'application. Qu'en est-il si un développeur néophyte souhaite développer une appli complète sur la pase de Pluf ? Et ben ça fait plouf !

Ton comparatif m'intéressera lorsque tu feras le détail du niveau de fonctionnalité offertes, point par point. J'ai contribué au livre blanc publié par Clever Age récemment : http://lacot.org/blog/2008/05/14/php-frameworks-for-business.html

Voici les grands critères de comparaison que nous avons recensés :

Risques pour l'utilisateur, Système de Vues, Performances, Routage, Internationalisation et régionalisation, Outillage, (Journaux, Debuggage, Scaffolding, Command Line Interface), Environnements de développement, Intégration avec des briques externes, Respect des standards (Standards XHTML : respect du balisage, Standards de développement, utilisation de librairies reconnues, Implémentation correcte des RFC), Ajax, Extensibilité, Authentification et permissions, Sécurité, Déploiement, Tests unitaires et fonctionnels, Courbe d'apprentissage, Aspects légaux, Modularité, Indépendance stratégique, Assurance qualité, Support, Facilité d'extension du code

Sur lesquels de ces critères penses-tu que ton framework est supérieur aux autres, ou au moins aussi riche ? Et si tu t'appelais Yahoo et que tu devais mettre en place la nouvelle version de Del.icio.us, que ferais-tu ? Utiliserais-tu Pluf ou un autre framework ?

p4bl0 said:

Mouais... Ça veux juste rien dire de faire le test sur du static. Enfin, ça test la vitesse que met le framework à afficher un truc statique sans faire de manip avant.

Sauf que cette données est totalement inintéressante... Effectivement si on ajoute un accès à une base de données ça fausse le résultats, mais il faudrait plutôt faire un test avec une fausse vraie page (si on peut dire) :

Dans l'action on load une classe (un faux modèle avec les données en dur dans PHP par exemple) et on range ces données de manière à les afficher dans la vue. Et dans la vue on affiche ces données dans une vraie page web et on utilise un helper (ou plugin, le nom dépend des framework).

Bien sûr il faut faire exactement les mêmes choses d'un framework à l'autre, et à ce moment là le benchmark aura du sens.

Parce que je vois sur le site de Pluf que Pluf a un moteur de template en php, en je pense que si on choisi de l'utiliser ça doit pas mal ralentir l'appli par rapport à utiliser PHP directement (par exemple).


Et pour avoir un vrai test alors il faut aussi tester le système de cache et compagnie de toutes façons... :-)

Loïc said:

Xavier, un néophyte (Nicolas) a intégré le support complet de subversion dans InDefero en 2 soirées. Donc pour ce qui est de la facilité d'apprentissage, je pense que cela répond en partie à la question.

Merci pour la liste des points d'évaluation du framework, je pense qu'il faudrait ajouter documentation et communauté. En effet, sur tous les points nommés, Pluf est très bon, mais sur la documentation et la communauté, il n'y a aucun doute, "peut mieux faire" est la réponse. Si je me rappelle de l'argumentaire de Yahoo, c'était bien communauté et documentation les points clefs.

Pour la performance, Yahoo a déjà tout le système de répartiteurs de charge etc... donc ajouter 50% de plus de machines car le framework bouffe de la performance par rapport à du PHP pur, ce n'est pas un problème pour eux. Mais pour une petite structure, il faut être réaliste, c'est un problème.

Sinon, merci de venir discuter ici, même si la discussion est un peu tendue, je l'apprécie beaucoup, car elle est de qualité.

Loïc said:

p4bl0, je prépare un article sur l'utilité et les limites d'un test de type "Hello World!", cela répondra en partie à vos remarques. Notez que le système de template de Pluf utilise le tokenizer de PHP et recompile le résultat en PHP pur donc on réduit le cycle au minimum.

Nicolas said:

Loïc, j'avais déjà utilisé Pluf il y a 6 mois, mais l'apprentissage est relativement rapide. J'étais donc juste néophyte au code d'indefero ;)

David, biologeek said:

C'est intéressant de voir chaque dev venir défendre son beefsteak :-)

Bon j'essaye de faire l'arbitre :
> Loïc : s'il te faut un système de mise en cache pour afficher "Hello World!" c'est qu'il y a un problème quelque part

Je ne suis pas vraiment d'accord, si la première requête pour mettre en cache est plus coûteuse mais que je gagne du temps sur les 1000 prochaines requêtes, je préfère et je ne connais aucun site qui ne soit pas en prod avec un minimum de cache.

> laurentj : Quant à Symfony 1.1, j'ai lu un peu son code, c'est devenu un véritable bloatware.

Soit mais est-ce utile au quotidien ? C'est ça la vraie question et ça dépend du projet donc il faut essayer d'adapter son choix de framework au projet mais comme on n'a pas le temps d'apprendre x frameworks, on se concentre sur une valeur sûre qui permettra de faire le café facilement lorsque le client demandera immanquablement cette fonctionnalité. Chacun sa stratégie à se niveau mais ça sert à rien de dénigrer le voisin.

> Xavier : Qu'en est-il si un développeur néophyte souhaite développer une appli complète sur la pase de Pluf ? Et ben ça fait plouf !

Huhu, bon pour revenir au fond (pas de l'eau), je me demande si un développeur néophyte existe vraiment, on a tous notre expérience et ça dépend de nos capacités d'adaptation.

Pour finir, je rejoins Xavier sur le fait que le matériel n'est plus vraiment un frein au niveau du budget (encore une fois ça dépend pour qui) et il ne faut pas oublier que ces problématiques de performances ne concernent qu'une minorité de sites. Faites des services intéressants et éclatez vous avec vos outils de prédilection, c'est le principal :-)

ps : la discussion sur l'autre billet m'a clairement touché et j'aurais l'occasion d'y revenir mais n'a en rien motivé le billet critique concernant celui-ci. Que les choses soient claires.

Laurentj said:

@xavier
> Étonnant qu'on n'ait pas entendu parler de Jelix. Vraiment étonnant.

Comment ça étonnant ? Ce n'est pas parce que tu ne semble pas le connaitre et qu'il n'est pas très connu, que c'est un mauvais framework hein. Des gros sites (à plusieurs millions de pages/jour) l'ont choisi, c'est pas un hasard non plus.

Désolé aussi si j'ai pas des centaines de milliers d'euros à dépenser dans le marketing et dans l'embauche de dev, pour promouvoir mon framework, comme le fait sensio, zend et cie avec leurs frameworks, avec leur armée de dev payés à temps plein pour maintenir la doc, les sites, etc..

Et puis d'ailleurs, je vois pas pourquoi tu nous parles de Jelix, vu que j'en ai pas parlé ici.

En tout cas, il est triste ton avis sur les frameworks "de bricolage amateur" (même si je ne considère pas mon framework comme tel)

Pour la mise en cache, si le cache est bien fait dans un framework, ça revient au framework à renvoyer du statique, donc l'équivalent d'un hello world (modulo le volume de la page) donc en théorie, il n'y a que la couche de routage/coordination qui entre en jeu. Et l'objectif du test du hello world, c'est justement de comparer les perfs de cette couche. Pas de comparer l'ensemble d'un framework. CQFD. (c 'est comme ça que je le prend en tout cas)

Quant à ton ensemble de critères pondérables, je vois pas le rapport avec la performance d'un framework. C'est pas en ayant une super doc de 3200 pages, 1235 classes utilitaires et 50 développeurs, que ça va en faire un truc super rapide.

Loïc said:

> Pour la mise en cache, si le cache est bien fait dans un framework, ça revient au framework à renvoyer du statique, donc l'équivalent d'un hello world (modulo le volume de la page) donc en théorie, il n'y a que la couche de routage/coordination qui entre en jeu. Et l'objectif du test du hello world, c'est justement de comparer les perfs de cette couche.

Exactement ! J'adhère à 100% avec cette remarque et c'est bien pour cela que j'ai fait ces tests.

Olivier said:

En même temps on mesure le "chemin de routage" pour vérifier qu'il soit bien pensé/conçu. Pourquoi le système de cache serait il quant à lui toujours irréprochable ? Après tout c'est probablement un élément clé du framework lui aussi, et j'ai vu pas mal de systèmes de cache qui utilisaient des mécanismes de verrous assez pénalisant.
Un test un peu plus approfondi prenant également en compte ce système de cache ne serait pas complètement inutile non plus.

Loïc said:

Olivier, je suis tout à fait d'accord, mais généralement le système de mise en cache se fait à un niveau à peu près égal au niveau de routage "de base" et donc fait quand même travailler le cœur de routage. On obtient quelque chose dans le genre :

Requête -> Routage -> Cache disponible Oui/Non -> Renvoi depuis le cache/Génération, mise en cache, renvoi.

Mais effectivement, cela serait intéressant de regarder une page "simple" (par exemple une page HTML de 2ko avec un sleep d'une seconde pour la génération) avec mise en cache.