Bench en cours, et autres frameworks
Par Laurentj le dimanche, janvier 7 2007, 14:15 - Projets - Lien permanent
Suite aux commentaires à mon précédent billet, on s'est mis d'accord, Gerald et moi, pour réaliser des benchs sur nos frameworks respectifs, à savoir Copix 3 et Jelix 1.0 dans leur version pre-beta (version trunk quoi...). On s'est donc mis d'accord sur une page type (voir la page en question sur le site http://bench.copix.org/).
De mon coté, je me suis remonté une machine, un vieux celeron 700 (overclocké à 808 Mhz), j'y ai installé les deux applis tests, et j'ai commencé à utiliser Tsung, qui est un outil de test de montée en charge performant et relativement simple à utiliser. Sauf en cluster : il n'y a pas de documentation claire pour ce type d'utilisation (mais je suis en train de me renseigner). J'aimerai en effet profiter de cette fonctionnalité avec l'aide des 3 autres machines de mon parc, afin de pousser le serveur au maximum (un processus Tsung ne peut simuler au maximum que 800 utilisateurs simultanés et il se bloque à 800 sans continuer à rajouter des utilisateurs, même quand des utilisateurs "se déconnectent", ce qui fausse un peu la suite des stats...).
Selon les premiers résultats, Jelix semble mieux tenir la charge que Copix, mais il faut quand même que je paufine encore les scénarios de tests pour confirmer.
J'ai voulu également faire les tests avec symfony. Mais après 2 heures de batailles avec ce framework, j'ai abandonné. Je ne suis pas arrivé dans ce laps de temps à afficher une simple liste d'enregistrement ! (documentation incomplète, ou obsolète &cie... mais bon, pas le temps de me justifier ici) Et ce n'est pas de la mauvaise volonté de ma part : je tiens vraiment à le bencher ce framework ! Mais hélas j'ai peu de temps :-/ Donc si quelqu'un pouvait me réaliser une appli symfony (avec la dernière beta) (mise à jour: c'est fait :-) ), affichant une simple page avec une serie d'enregistrement issus d'une table mysql comme celle qui suit, je lui en serais reconnaissant :-)
CREATE TABLE `bench_news` ( `id_bench_news` int(11) NOT NULL auto_increment, `title_bench_news` varchar(100) NOT NULL, `content_bench_news` text NOT NULL, `datetime_bench_news` varchar(14) NOT NULL, `author_bench_news` varchar(20) NOT NULL, PRIMARY KEY (`id_bench_news`) ) ENGINE=MyISAM AUTO_INCREMENT=5 DEFAULT CHARSET=latin1 AUTO_INCREMENT=5 ;
Et si une autre personne voulait bien faire la même chose avec le Zend Framework (ou autres framework), ce serait le pied. :-)
Bien sûr, je publierai un rapport complet des tests en toute transparence : description du mode opératoire, résultats détaillés de chaque test avec chaque framework, zip des applis etc. Mais ça va me prendre plus de temps que prévu...
Commentaires
Je ne suis pas très callé en frameworks, mais penses-tu qu'une simple page avec une liste permette réellement de départager les différentes applis ? J'ai le sentiment que les résultats vont être proches pour tous les frameworks; peut-être que l'écart se creuserait avec un bench sur une page plus complexe... Enfin on verra les résultats.
À propos de benchs de frameworks, il y a un petit test intéressant sur le blog de Paul M. Jones.
De mon côté, je travaille avec Cake. Si ça intéresse de le rajouter...
giz404 : oui je pense que ça permet de départager les frameworks. Comme c'est une page simple, alors sur le temps d'execution totale, la part de temps relative au traitements du framework même est assez importante par rapport à la part de temps relative à l'exécution du fonctionnel. Si par exemple, j'avais décidé de faire une action qui exécute un gros calcul mathématique, le temps d'exécution des objets du framework sera devenu insignifiant (le calcul n'impliquant que trés peu voir pas du tout les objets du framework). Donc je fais simple, pour que la part d'execution du framework soit suffisamment importante, pour que les différences entre framework se voit vraiment. (tu va me dire, j'aurai pu faire afficher un simple hello world, mais c'est moins représentatif de ce qui est fait avec un framework :-) ).
En définitive donc, on verra mieux les différences entre framework. Le plus performant sera celui qui fera les initialisations, les dispatchs des actions et autres trucs non "fonctionnels", le plus rapidement possible.
Et sinon, si tu exécute juste une page comme ça, il est clair que tu ne va pas voir la différence. Mais avec des tests de charges, les résultats ne sont pas si proche que ça : vu le nombre de requête qu'ils encaissent, les différences sont multipliés par toutes ces requêtes. En admettant qu'entre le framework A et B il y a 0.01 secondes de différences sur une page, avec 10,20, 50 requêtes par secondes, les différences se voient vite sur les courbes :-) (y aura des beaux graphiques dans mon rapport, générés par Tsung). Sans compter que plus il y a de requêtes à traiter en même temps, plus le temps d'exécution d'une seule requête augmente. Donc ces 0.01 peuvent devenir 0.5, 2 ,ou plus. Et on voit alors sur les courbes, le serveur s'écrouler :-)
Rik : ça m'interresse aussi beaucoup. Envoi moi ça ! :-) et si tu pouvais faire en sorte que ton template génère un code html identique aux autres, ca m'aidera aussi :-)
C'est un peu limitant de se contenter de d'un simple test de vitesse pour départager des frameworks mais c'est vrai que c'est une donnée qui peut être intéressante si on la garde dans son contexte.
Concernant Symphony il est ORM indépendant donc on peut choisir son moteur de persistance - il faudrait donc en choisir un pour le benchmark (pour l'instant Propel et Doctrine sont disponibles je crois).
Bon courage
Est-ce qu'on prend en compte le cache HTTP ? Parce que ça influe aussi sur les performances, même si c'est de façon moindre.
Olivier : bien évidement, un bench reste un bench, c'est à dire que les résultats ne donne qu'une estimation de la performance de la chose testée à partir d'un contexte donné. M'enfin quand même, cela n'empêche pas de constater les défauts et avantages.
Conçernant symfony, je ne suis pas si optimiste que toi. Vu le code bloated du truc (43 includes rien que pour faire un hello world, ils font fort chez symfony ! http://paul-m-jones.com/blog/?p=236 ), j'ai des doutes en la capacité de symfony a bien supporter les montées en charge (en hébergement normal en tout cas ).
loufoque : non, pas de cache http. c'est pas le but non plus. Le but est de tester les performances d'un framework, pas d'une appli (nuances ;-)
Une petite astuce qui peut t'éviter qq heures de casse tête avec tsung en mode cluster : ajoute le nom DNS de tes machines dans les fichiers /etc/hosts de chaque machine, sinon le process erlang va partir en timeout sans dire pourquoi. J'ai utilisé tsung du temps où il s'appelait encore idx-tsunami et j'ai simulé jusqu'à 10000 connexions.
Vrai ! Mon choix est donc fait. J'utiliserai Jelix pour les sites où je n'aurai que "hello world" à afficher sur ma page d'accueil, et symfony pour mes applications un peu plus consistantes ;).
Sincérement quel est l'intérêt des benchs entre 2 applis dont on sait que l'une est beaucoup plus lourdes que l'autres ?
Merci pour ces précisions ! J'attends avec impatience les résultats.
Je ne suis pas "particulièrement optimiste" pour Symfony. Je disais simplement que, si on part sur cette forme de test, il faut choisir avec soin l'ORM que l'on va utiliser. Pour installer doctrine :
http://www.prendreuncafe.com/blog/post/2007/01/07/Utiliser-Doctrine-au-lieu-de-Propel-dans-Symfony-sous-Ubuntu
J'attends avec impatience le mode opératoire et les résultats.
Bon courage encore
Olivier
Olivier : non, je ne prend que ce que ce que propose par défaut les frameworks. Si il faut en plus que je fasse des bidouilles, j'en ai encore pour des semaines à tester... (parce que bien sûr, qui dit bidouille sur l'un, dit bidouille sur les autres, pour que le match soit équitable...)
Pour vérifier que l'une est vraiment plus lourde que l'autre justement. Mais peut être que les algorithmes du framework lourd sont mieux foutu que celui du léger, donc plus rapide. Ou peut être pas... Seuls les chiffres pourront le dire... (et pas moi avec mes suppositions en ayant regardé quelques dizaines de minutes le core de symfony)
@giz404 > Je suis assez d'accord avec toi dans le sens ou le bench "à lui seul" sur une page simple ne permet pas de choisir un framework. Toutefois, cela donnera des résultats "bruts" sur les performances des dits frameworks avec une page simple.
Par la suite, je pense qu'on pourrait agrémenter les jeux de tests avec des pages plus complexes.
Je lance en ce moment quelques tests de mon coté en utilisant JMeter et deux machines différentes (un client et un serveur).
Justement les chiffres diraient quelque chose si ils étaient mesurés sur des algorithmes mais et non directement sur l'appli.
De nombreux benchs ont été fait entre frameworks PHP, Symfony est toujours en queue de peloton... Je ne connais pas Jelix mais je me doute un peu du résultat de tes benchs ;).
Symfony n'est certainement pas adapté pour tous les développements mais c'est certainement le framework PHP le plus flexible qui soit. Maintenir un haut niveau de flexibilité et un très gros volume de fonctionnalités, cela a un coût c'est sûr.
@Cyrille > De mon coté, je suis assez d'accord avec ce que tu dis. Toutefois, ici nous ne testons que la "performance brute" qui est une composante du choix. Si un jour il faut choisir un framework, ce n'est bien évidemment pas le seul critère à prendre en considération, il faut regarder la facilité de prise en main, de maintenance, la stabilité, l'évolution, la couverture foncitonnelle, ..., ... et ses affinités !
Je suis tout à fait d'accord avec Gerald. Je ne pretend pas avec mes tests déclarer un framework meilleur qu'un autre. Juste que sur un point particulier, tel framework est devant un autre.
Un framework se choisi en fonction de ses besoins. Si par exemple c'est pour un site à frequentation modeste, et qu'on veut faire de l'ajax à gogo, symfony semble être un bon choix. Mais si c'est pour un site à forte fréquentation et que pour l'ajax, on peut s'en tenir à des libs externes, il va falloir se tourner vers d'autres frameworks..
Et encore, pour le choix d'un framework lourd, cela dépend sur quoi on l'héberge. Si c'est sur de l'hébergement dedié avec php en cgi (beurk) ou fortement chargé, là faudra soit changer d'hébergeur, soit voir un autre framework.
Salut, juste pour info, un autre test comparant 3 frameworks : Synfony (php), Ruby on Rails (Ruby) et Django (Python).
Et je suis aussi d'accord avec ce qui a été dis plus haut, on choisi son framework en fonction de ce qu'on veut faire avec. Si c'est pour faire du "hello world", pas besoin de framework.
Donc la performance n'est pas le seul point à regarder pour faire un choix, même si c'est quand même très interressant de savoir à quoi s'attendre.
et j'oublie de mettre le lien :) c'est par là : http://wiki.rubyonrails.com/rails/pages/Framework+Performance
lozit : le bench que tu presentes est vraiment discutable, car il y a beaucoup trop de choses qui changent d'un test à un autre : ils ne sont pas effectués dans les mêmes conditions. Non seulement il y a le serveur http qui change, mais aussi le langage et enfin le framework.
Pour moi ce bench ne veut rien dire du tout. En effet, en fin de compte, qu'est ce qui fait qu'un framework est plus rapide qu'un autre ? L'usage d'apache ou de lighttpd ? l'usage de php ou de ruby ou de python ? etc..
Oui ce n'est pas faux, d'un autre coté il semble qu'ils aient fait un test sur des configs optimisées pour chaque système.
Surtout que chaque defenseur de chaque techno pourra toujours dire (a juste titre) qu'on peut améliorer les performances en échange d'un peu de tunning.
C'est sur que de comparer des frameworks php sur la meme machine avec les memes softs installés, c'est déjà beaucoup plus fiable.
Mais c'est toujours interressant d'avoir un test de plus :)