Réponse aux réponses sur les frameworks PHP et le test Hello World!
The 2008-09-04 at 07:37 by Loïc d'Anterroches filed under Pluf - Framework en PHP5.
David a un framework plus rapide que Pluf, je verse une larme, Pluf vient de perdre la première place ;-) C’est de bonne guerre.
Je reprends un commentaire fait sur le billet de David ici :
Nous sommes tous les deux des scientifiques pragmatiques, donc bon, on sait tous les deux où se trouve la valeur ajoutée d’un framework de développement web : nulle part ou presque. Dans le sens où aujourd’hui on ne peut rien faire sans et que le choix X ou Y est principalement une question de goût.
D’ailleurs, notre valeur ajoutée est bien au delà de tout ça, grosso modo, je ne gagne pas un rond avec Django & Cie, mais je gagne en utilisant Django pour fournir de l’application de calcul scientifique. Être spécialiste dans un domaine très pointu permet de travailler un mois par an et s’amuser le reste du temps.
Un article qui exprime bien ce que je pense, écrit en 2004, il est toujours d’actualité, particulièrement les 2 derniers paragraphes : Logiciel libre et entreprise.
Je vous invite vraiment à lire cet article.
Maintenant je remercie particulièrement Oncle Tom, Xavier et David pour être venus ici discuter d’un sujet trollesque avec professionnalisme et courtoisie, cela montre la qualité des personnes derrière les écrits et ça, c’est l’important.
Comments from readers
Laurentj said:
Ce serait vraiment, mais alors vraiment bien, si tu pouvais fournir ton appli hello world, parce que l'utilisation de ton framework pour faire un simple hello world, n'est absolument pas intuitive je trouve, surtout sans aucune doc (non, les 5 pages dans la partie documentation ne sont pas une doc :-p). Et comprendre la logique de fonctionnement de pluf dans les deux exemples super complexe fourni avec le framework, c'est pas aisé.
Si j'avais 2 heures devant moi, je pense que je finirai bien par comprendre, mais je n'ai pas autant de temps (et je pense que des dev qui débarquent sur le site de pluf, ne vont pas tous faire l'effort d'aller décortiquer le code pour comprendre comment faire un simple hello world). Pourtant j'aimerai bien faire un hello world, juste pour lancer les bench et comparer avec jelix :-p
Loïc said:
Oui, bon, je sais, cette doc n'est pas encore au top... si un jour elle y arrive :)
http://xhtml.net/documents/breves/2008/test-helloworld.zip
Pour aller vite, tu fais un checkout de Pluf dans ton docroot, tu copies le contenu de l'archive au même niveau que le fichier Pluf.php, tu auras le fichier index.php dans le même répertoire que Pluf.php (comme cela tu n'as pas besoin de t'occuper de mettre le chemin vers Pluf.php dans l'include_path).
Ensuite, tu appelles http://localhost/cheminvers/index.php/hello/
N'hésite pas à me demander de l'aide au besoin, dès que tu as des résultats avec aussi ceux de Jelix, je suis prêt à faire un lien du billet du test vers tes résultats.
Je suis particulièrement intéressé par les résultats de Jelix.
Laurentj said:
Ok merci :-)
j'ai pu faire fonctionner ton hello world. Les benchs sont en cours...
J'ai déjà fait une première serie (sans pluf) mais sans cache d'opcode.
1) Jelix-trunk edition gold (114 req/s)
2) solar 1.0 alpha (111 req/s)
3) jelix 1.0.6pre édition dev (105 req/s)
4) jelix trunk edition opt (87 req/s)
5) jelix trunk edition dev (86 req/s)
le reste (zend, symfony, cake..) c'est en dessous de 40, sachant que le pire est cake avec 26 req/s et que baseline-php est à 3279 req/s
Je viens d'installer eaccelerator (j'ai pas de paquet xcache), et je viens de relancer les benchs, en incluant pluf... stay tune :-)
Loïc said:
Génial ! C'est déjà bien prometteur pour Jelix. Au passage, j'ai ajouté une mini doc pour faire un hello world avec Pluf :
http://pluf.org/doc/hello-world.html
Laurentj said:
Bon, j'obtiens des résultats vraiment étranges avec eaccelerator installé, genre complètement l'inverse avec jelix et de grosses différences entre la 1.0.6pre et le trunk alors que le code mis en oeuvre pour faire ce hello world n'a quasiement pas bougé depuis la 1.0. Je ne comprend pas pourquoi. vraiment vraiment bizarre. Par contre apparement pluf est effectivement plus rapide.
Mais est ce que le routage et la coordination (puisque c'est ça que l'on test) de pluf offrent les même possibilités que dans les autres frameworks, c'est à voir ;-)
Loïc said:
Quand j'ai testé Pluf pour le première fois je faisais une requête par 15s. 15s, exactement le timeout de Apache pour le keepalive.
Le problème venait que je définissait le code HTTP comme étant en 1.1 au lieu de retourner un 1.0, cela mettait ab dans les choux.
Par ailleurs, avec un opcode, il faut fuir les include_once, Pluf n'utilise que des include simples. Tu peux utiliser xdebug faire un profil pour regarde ce qui se passe avec kcachegrind (j'ai optimisé l'ORM de Pluf comme cela, cela fonctionne vraiment très bien).
Pour le routage de Pluf, cela offre les mêmes possibilités que Django, c'est une liste ordonnée de preg_match pour le dispatch avec possibilité d'ajouter des middleware pour changer la requête et/ou la réponse pour l'ensemble des vues et des préconditions sur les vues au cas par cas. Je n'ai pas encore touché les limites, donc cela me va.
Laurentj said:
Je renvoi bien du HTTP 1.0. Et concernant les include, la version de jelix qui inclus toutes les classes du coeur dans un seul fichier est beaucoup plus lente que la version multi-fichier, donc de ce coté là, à priori, c'est pas les include_once le problème (et je fais des require pour les fichiers dont je suis sûr qu'il ne seront pas inclus deux fois). Alors que sans cache, c'est plus rapide. Les caches d'opcode n'aimeraient-ils pas les gros fichiers php ? (pourtant ce gros fichier est bien mis en cache)
Je regarderai avec xdebug mais il faut désactiver le cache pour qu'il fonctionne correctement, donc pas sûr que je vais voir le problème...
Loïc said:
Si tu veux, tu peux me faire un zip quelque part avec tes différentes versions et pour chacune le hello world. Histoire que je puisse juste mettre cela dans mon docroot pour tester. Je peux faire les tests en local sur ma machine et sur une instance EC2. Je garderai les résultats entre nous, le temps que tu arrives à trouver la raison du problème, si vraiment il y a un problème.