Pluf, le framework PHP le plus rapide du monde (troll)
The 2009-10-23 at 09:01 by Loïc d'Anterroches filed under Pluf - Framework en PHP5.
Si vous ne connaissez pas Pluf, le framework PHP le plus rapide du monde, je vous invite à lire une petit brève ici et un benchmark de framework PHP là, vous pouvez aussi lire comment je tire à vue sur certains développements ici avec un benchmark de template PHP là.
Pluf, le framework PHP le plus rapide du monde, c’est aussi un joli troll dans les chaumières des développeurs PHP, il semble que cela commence même à troller dans les SSII sur le sujet. Aïe, pour un programmeur, voir son code être le sujet d’un troll, cela peut paraître ennuyeux, mais dans mon cas, cela me fait très plaisir. Je ne suis pas sado, loin de là, mais essayer de faire passer une idée qui va à l’encontre des pratiques du moment est toujours difficile.
Donc à toutes les personnes qui se moquent, je vous dis merci, et je vous dis surtout continuez ! Continuez de troller sur la rapidité du framework X par rapport au Y.
Maintenant pourquoi je tape sur les bibliothèques et frameworks PHP qui ne font que prendre du poids avec le temps ?
InDefero est une application web dite de forge logicielle. Vous pouvez au choix la télécharger (licence GPL) ou profiter d’un hébergement pour vous contre quelques Euros. L’hébergement InDefero c’est 1500 forges dont 1300 d’actives. Quand vous gérez cela, vous gérez un système qui au niveau performance doit supporter 50 à 100 fois plus de charge qu’une installation unique (la charge se répartie dans la journée avec les fuseaux horaires, donc ce n’est pas un facteur 1000).
Un facteur de 50 à 100, cela veut dire que très rapidement, si vous utilisez des bibliothèques qui font trop, votre composant web va s’essouffler, en gros votre serveur web ne va plus ternir la charge tout seul. Il faut être réaliste, dans la majorité des applications web, la logique métier est principalement de la requête sur la base de données. Donc on peut faire un calcul simple, de derrière d’une enveloppe et décomposer une requête web en 2 parties, logique métier et framework :
- logique métier: 50ms par requête ;
- logique framework: 50ms par requête.
On obtient donc une réponse en 100ms pour une requête, performance tout à fait honorable, on va l’appeler le cas optimisé.
Maintenant, je tape dès que je vais des facteurs 3 à 5 sur les performances des bibliothèques. Comme la logique métier est incompressible on obtient :
- logique métier: 50 ms par requête (ne change pas) ;
- logique framework: environ 150 ms par requête (facteur 3).
Total 200 ms, un facteur 2.
Cela veut dire quoi ? Cela veut dire que votre ensemble DB + serveur web va avoir besoin de 2 fois plus de cycles CPU pour servir la même charge. Cela veut dire que votre coût pour faire croître votre site va être multiplié par 2.
En fait c’est pas très juste, le premier goulot dans une architecture share nothing est toujours la base de données. Donc dès que le système ne tient plus, on déporte la base sur son serveur propre. Maintenant, on refait le calcul mais on prend en compte la distinction serveur de BD et serveur Web.
Version optimisée par requête :
- logique métier: 50ms par requête (serveur BD) ;
- logique framework: 50ms par requête (serveur Web).
Version lourde :
- logique métier: 50 ms par requête (ne change pas, serveur BD) ;
- logique framework: environ 150 ms par requête (facteur 3, serveur Web).
Maintenant, si on suppose que dans le cas optimisé un serveur web peut saturer un serveur de BD, on obtient pour assurer la même charge :
- Version optimisée : 1 serveur web et 1 serveur de base de données.
- Version lourde : 3 serveurs web et 1 serveur de base de données.
Facteur 2 au total, mais un facteur 3 sur le front end. Je vous laisse penser à tous les problèmes de répartition de la charge et de synchronisation du code que cela implique ainsi que les coûts associés. Bien entendu c’est du calcul de dos d’enveloppe donc à prendre comme un ordre de grandeur surtout l’approximation logique métier équivalente aux requêtes vers la base de données.
Pourquoi un différence si importante ? Car à tous les échelons, le choix à été fait de prendre la solution qui fait plus au cas où qui n’arrive dans 99% des cas jamais mais qui coûte 3 fois plus de cycles. L’agilité c’est introduire dans un système la complexité strictement nécessaire et suffisante en choisissant les bons outils et en refactorisant en continu. C’est très dur (j’ai vraiment du mal) mais cela vaut la peine !
Note pour les trolls : je pars en WE et ne vais avoir le temps de répondre que lundi.
Comments from readers
jérémy said:
"Facteur 2 au total, mais un facteur 3 sur le front end. Je vous laisse penser à tous les problèmes de répartition de la charge et de synchronisation du code que cela implique ainsi que les coûts associés"
Le déploiement et répartition de charge sur plusieurs Front n'est pas un casse tête, ce n'est peut être pas ton métier, mais ça n'est pas un si gros problème.
desfrenes said:
"ce n'est peut être pas ton métier, mais ça n'est pas un si gros problème"
oui... mais:
ça coûte combien de s'offrir les services de quelqu'un dont c'est le métier ?
et ça coûte combien un front de plus ?
thibault said:
Et avec les caches activivés ? (oui, c'est vendredi soir, c'est le moment des commentaires improductifs).
Hugo said:
Hello,
Je vais prendre le temps de répondre à ton --troll-- billet qui ne me surprend pas avec tout ce que j'ai lu précédemment ici. Je ne partage pas tout à fait ton opinion concernant les performances des frameworks. En effet, les performances sont un sujet très sensible qu'il faut aborder avec beaucoup de pincettes car elles dépendent tout particulièrement du contexte. Pour moi les performances doivent passer largement au deuxième plan dans la construction d'un projet sauf cas exceptionnel. En effet, je serai curieux de savoir combien de clients réels (y compris dans les grands comptes) demandent explicitement que leur site web soit très performant. C'est quoi "être performant" pour le client ? C'est quoi "être performant" pour le prestataire ? Les deux parties n'ont pas la même vision des choses. Le client, ce qu'il souhaitera avant tout, c'est que le prestataire lui livre une application qu'il a financé et qui fonctionne d'après les spécifications. Si ensuite l'application répond à ses besoins en terme de fonctionnalités et de "rapidité" alors la mission sera réussie, quel que soit les outils utilisés pour y parvenir. En revanche, si le client s'appelle Amazon, Google, Yahoo!, Dailymotion, RueDuCommerce ou autre, alors je peux comprendre que les enjeux de performances sont importants car ils impactent immédiatement leur chiffre d'affaire. Reprends moi si je me trompe, mais je suis certain que ces clients comprennent combien il est important pour eux d'assurer les performances. Par conséquent, ils seront prêt à aligner l'argent nécessaire pour se payer des machines.
De plus, je te rappelle que les performances les plus dramatiques ne sont pas côté serveur mais bel et bien côté client. Est-ce que tu compresses bien tous tes JS et CSS ? Est-ce que tu utilises un CDN pour des contenus statiques ? Est ce que tu as bien défini tes entêtes HTTP Expire quand tu mets une application en production ? Est ce que ton code HTML est bien synthétique ? Si tu arrives à chaque fois, alors je m'incline mais dans ce cas c'est que tu y passes certainement plus de temps (donc d'argent) que peuvent peut être en coûter l'achat d'un serveur supplémentaire...
Revenons aux frameworks en eux-mêmes et le débat que tu soulèves : les performances des frameworks. Pourquoi de nombreux clients préfèrent faire confiance à des frameworks éprouvés (symfony et zend framework entre autres) pour leurs applications, plutôt que Pluf, quitte à perdre légèrement niveau performance ? Il n'y a pas à réfléchir longtemps pour s'en convaincre. De nombreuses raisons sont identifiables :
* Ils sont reconnus et pérennes. Pluf par contre...
* Ils sont supportés par d'importes communautés. Et Pluf ?
* Il y'a du support technique professionnel derrière grâce aux sociétés qui les supportent. C'est pareil pour Pluf ?
* Il est facile de trouver des formations à ces frameworks partout en France. Pour Pluf, je n'ai jamais trouvé de formation dans le moindre catalogue...
* Les mises à jour de versions en versions sont sûres. Est-ce le cas pour Pluf ?
* Ce sont des frameworks très outillés pour gagner du temps de développement. Pluf est encore loin de proposer un tel outillage pour des solutions professionnelles.
* Des grands comptes les utilisent (EDF, BNP Paribas, L'Oréal, PSA Peugeot Citroën, Nestlé...). Combien de grands comptes utilisent Pluf (désolé je ne pouvais pas m'en empêcher).
* On trouve plus facilement des développeurs Symfony, ZF ou CakePHP sur le marché que des développeurs Pluf.
* Ils sont largement documentés (livres, doc en ligne, blogs...) alors que Pluf, bah voilà quoi...
* ...
Bref, je ne vais pas étendre cette liste plus longtemps mais tu fais l'apologie de ton framework, soit disant parce qu'il est plus performant (benchs à la clé) que les autres. Ok très bien, c'est ton argument de "vente". Mais au final, qui utilise ton Pluf ? Qui supporte ton Pluf ? Si personne ne s'y intéresse réellement c'est qu'il n'est pas à la hauteur de ce que recherche les développeurs. Un développeur professionnel veut avant tout un outil qui lui fera gagner du temps qui intègre génération de code, tests unitaires et fonctionnels, sécurité, abstraction de BDD, I18N & L10N... pour répondre à des problématiques complexes et récurrentes. Et c'est ce qu'ont compris les frameworks Zend et Symfony puisque tous leurs outils ont été intégrés suite à des réels besoins clients au fil des années.
Je te laisse faire joujou avec ton Pluf et moi je retourne travailler avec un vrai framework RAD agile qui me fait gagner du temps, et qui me procure du plaisir quand je développe avec.
;)
Kev said:
Ha merci Hugo,
tu as su prendre le temps de repondre a ce post qui, comme les autres de ce blog, pollue le planet "php fr" trop regulierement!
Clochix said:
A Hugo et Kev : je pense que vous avez oublié le dernier mot du titre. J'avoue ne pas avoir la même lecture que vous des billets de Loïc. Je les prend au second degré, davantage comme une parodie des concours puérils de taille d'organe auxquels se livrent certains bloggueurs. En matière de logiciels comme dans bien d'autres domaines, la performance ne fait pas tout, défendre le contraire est pour moi signe de manque de jugeote, de suffisance ou d'appétit pour le troll. Et j'aurais plus tendance à classer Loïc dans la 3° catégorie.
desfrenes said:
"Des grands comptes les utilisent"
si tu savais ce que les grands comptes utilisent parfois... ^_^ (http://fr.thedailywtf.com/Articles/Framework-dentreprise.aspx)
"je suis certain que ces clients comprennent combien il est important pour eux d'assurer les performances. Par conséquent, ils seront prêt à aligner l'argent nécessaire pour se payer des machines."
Je comprend pas cet état d'esprit... "ça rame ? rajoute des lames, ça ne coute pas cher et ça rêgle tous les problêmes !" euh, non désolé, ça ne marche pas comme ça dans la vraie vie. Ajouter des machines ça coute cher, les gérer aussi. ça peut même couter de l'argent en développement quand l'appli n'a pas été pensée pour pouvoir supporter une montée en charge horizontale.
Optimiser son application ce n'est pas gratuit non plus mais ça fait parti, il me semble, à un moment donné du travail du dev. Par ailleurs, consommer moins de watts c'est bon pour tout le monde.
"Pourquoi de nombreux clients préfèrent faire confiance à des frameworks éprouvés"
Il y a, aussi, une part d'irrationnel, non négligeable. "C'est connu, donc ça doit être bien, donc je suis rassuré."
Au final je trouve qu'il est dommage d'avoir à choisir entre performances / consommation de ressources et fonctionnalités / support, etc... c'est pour ça que je ne vois pas ce genre de post comme de la pollution mais plutôt comme un rappel utile d'une probématique trop souvent mise de coté par les "gros" acteurs. Ou sinon autant qu'on fasse tous du J2EE, là au moins ce sera supporté, pérenne, reconnu, avec des formations et tout... et beaucoup plus de serveurs qui viendront solliciter edf.
"je retourne travailler avec un vrai framework RAD agile qui me fait gagner du temps, et qui me procure du plaisir quand je développe avec"
A priori je dirai qu'il ne s'agit pas de ZF... j'ai bon ? ^_^
Hugo said:
>> si tu savais ce que les grands comptes utilisent parfois... ^_^ (http://fr.thedailywtf.com/Articles/Framework-dentreprise.aspx)
Oui ils n'utilisent pas tous des frameworks éprouvés. C'est aussi lié à leur architecture déjà en place depuis des années qu'ils ne veulent pas trop bousculer malheureusement. C'est généralement avec les grands comptes que l'on a le plus de mal à faire bouger les DSIs vers des technos plus matûres et modernes.
>> Je comprend pas cet état d'esprit... "ça rame ? rajoute des lames, ça ne coute pas cher et ça rêgle tous les problêmes !" euh, non désolé, ça ne marche pas comme ça dans la vraie vie.
Je suis d'accord même si cela se fait beaucoup. Je te suis entièrement dans la démarche de dire que le développeur doit prendre en charge un minimum les problématiques de performances (compression des assets, optimisation des requêtes SQL, optimisation du code...). Néanmoins, tout cela peut coûter vite très cher si l'on y passe trop de temps. Et on sait tous que les budgets dev sont souvent les plus ingrats. On préfère parfois investir beaucoup d'argent du budget du client dans la recherche de l'identité graphique car c'est ce qu'il verra au final. Le dev c'est toujours la dernière étape et on dit souvent aux développeurs : "il te reste seulement X jours alors développe vite et bien parce que la livraison c'est pour hier". On en arrive donc au fait que l'on se concentre davantage sur l'aspect fonctionnel, puis on voit plus tard pour l'optimisation générale. En revanche, si les performances sont véritablement stratégiques pour le client, dans ce cas, on lui fera comprendre dès le début qu'il devra être prêt à investir plus d'argent dans son projet afin que les développeurs puissent avoir du temps alloué aux optimisations. C'est ce que je disais, le thème des performance est un sujet délicat qui est fortement lié au contexte du projet et du client. Et on ne peut pas affirmer qu'il faut optimiser chaque projet. C'est impossible, surtout que pour de nombreux projets, optimiser sera surtout plus une perte financière au vue des réels enjeux stratégiques du projet développé.
>> A priori je dirai qu'il ne s'agit pas de ZF... j'ai bon ? ^_^
Effectivement, ce n'est pas du ZF ^^
Loïc said:
Merci Hugo, desfrenes et Clochix pour vos commentaires. Hugo, je ne fais pas de la publicité pour Pluf mais surtout pour l'idée derrière Pluf et je pense que sincèrement tous les frameworks peuvent améliorer leur performances. Jai surtout Pluf car je suis du genre à faire ce que je dis (et que j'aime l'approche de Django, aussi).
En fait, les commentaires montrent bien qu'il y a deux approches dans le choix des outils l'une qui considère les fonctionnalités puis les performances et l'approche inverse.
Je comprends tout à fait que dans une SSII on choisisse le chemin des fonctionnalités d'abord. Mais en prenant ce chemin, on accepte d'embarquer avec son application de la fonctionnalité inutilisée qui a trop souvent un impact au niveau des performances. C'est un fait, une fois le choix fait, il faut l'assumer. C'est un choix de "performance suffisante" car la performance est le second critère.
Je propose une approche retournée où le choix est d'abord de performance avec les "fonctionnalités suffisantes". Et suffisante cela ne veut pas dire coder en assembleur l'interface CGI, je veux quand même pouvoir coder rapidement et avoir un logiciel au final facile à maintenir et pour lequel des contributeurs soient prêts à coder.
J'essaye juste de faire prendre conscience de ces choix qui sont très souvent faits de manière implicite.
Note pour Jérémy, si ton "moteur" prend 250ms pour générer une page, tu peux mettre autant de serveurs en front-end, ton client n'aura pas sa page en 100ms.
Note pour l'anonyme Kev, je pense que vos dons de programmeurs sont suffisant pour facilement coder un filtre qui exclurait toutes mes contributions de vos lectures.