PHPFrance

[Nagol]

Je ne vais pas rentrer dans la description nexen le fais très bien donc voici le lien:

http://www.nexen.net/actualites/php/186 ... usions.php

[Cyrano]

Le meilleur commentaire de cet article est à mon avis le suivant:

1. It all starts with "I don’t need a framework."
2. Then you create 7 classes.
3. Now you have a small library of classes.
4. Then you create an application that uses your library.
5. It works and it’s fast, hurray!
6. Then someone asks you to extend the functionality of your application.
7. And they keep asking for more, and more, and more and more…
8. Now you have 43 classes.
9. You’ve learn so much in the last 2 years. Design patterns, security, performance, testing…
10. What once was a small library is now a big, ugly, un-tested, un-documented, scary framework.
11. Then you change jobs.
12. And you create another 7 classes...

Traduction pour les non anglophones :

1. Tout commence avec "Je n'ai pas besoin d'un framework."
2. Ensuite vous créez 7 classes.
3. Maintenant vous avez une petite librairie de classes.
4. Puis vous créez une application utilisant votre librairie.
5. Ça marche et c'est rapide, hourra!
6. Puis quelqu'un demande une extension à une fonctionnalité de votre application.
7. Et ils continuent à vous en demander plus, et plus, et plus, et plus...
8. Vous avez maintenant 43 classes.
9. Vous avez beaucoup appris lors des deux dernières années. Design patterns, sécurité, performance, tests...
10. Ce qui était une petite librairie est devenu un énorme, laid, non-testé, non-documenté, effrayant framework.
11. Puis vous changez de boulot.
12. Et vous créez à nouveau 7 classes...

C'est curieux que si peu réagissent à ce type d'article. Ça fait déjà un moment que Rasmus a dit que les frameworks, c'est bien ... pour ceux qui les écrivent. Il enfonce aujourd'hui le clou avec cette batterie de tests.

Je crois que ça soulève un incontestable problème de méthodologie dans la programmation mais aussi un point peut-être plus grave : on essaye de tout faire avec PHP alors qu'en fin de compte on voudrait faire des choses pour lesquelles ce langage n'est pas approprié.

Un peu comme on a vu fleurir des sites Full-Flash lorsque ce type de média est apparu, puis du Full-Ajax lorsque les navigateurs se sont mis à supporter cette technique, on voit de plus en plus des applications en Full-PHP et... on va droit au casse-gueule, moins rapidement peut-être, mais on y va sûrement. Le sens de la mesure et des choix appropriés selon les besoins semblent absent trop souvent... Et puis j'ai l'impression (peut-être à tort notez bien) que certains s'ingénient à tenter de programmer en PHP de la même manière qu'on le fait en Java. Le résultat, ce sont des sites de plus en plus lourds... et lents. La programmation qui est derrière se veut hyper-professionelle avec des modélisations énormes, des framerowks testés et re-testés, des architectures super-évoluées... mais en oubliant des règles de bases de l'internet qui sont pourtant très loin d'être neuves et toujours d'actualité :
- l'internaute lambda est lent;
- l'internaute lambda est pressé.

À cet égard, un récent article de Nexen soulignait ce point : (source Nexen)

"La latence a un coût. Amazon a découvert que chaque 100ms de latence lui coûte 1% de ses ventes. Google a aussi remarqué que chaque .5 seconde de retard dans la génération des pages de résultats réduit son trafic de 20%. "

Ouch! un peu de retard dans la livraison d'une page, et les utilisateurs sont déjà ailleurs, à cliquer sur un site qui répond vite et bien. C'est impressionnant. Comment faire pour éviter la latence? Accélérer le serveur ou le faire évoluer est évidemment la première idée, mais il y a d'autres stratégie : les traitements asynchrones, qui lancent une opération en tâche de fond, mais sont capables d'occuper l'utilisateur pendant ce temps, les architectures BASE et non plus ACID (où la vitesse de réaction a priorité sur la cohérence des résultats).

[zeus]

Aujourd'hui, ce qui intéresse la grande société informatique, c'est de réduire les temps de développement. Et c'est ce qui tente dans le Framework.
Concernant les performances, il existe une multitude de solution pour réduire les surcouche apportées par un framework, le cache d'opcode en tête.

Sinon, il y a un truc que je ne vois pas apparaitre sur le bench, c'est la méthodologie
Utilisateur averti de Symfony, je sais que je suis capable de decupler sa puissance, tout dépend les outils que je met autour ...
Entre le système de cache intégré, les configurations de production et autres cache d'opcode, les performances changent du tout au tout.

J'aurais donc apprécié en savoir un peu plus que

Symfony 1.1 : 101 req/s

Et ça, pour chacun des framework testés

[Sékiltoyai]

Il sera toujours moins cher de multiplier les serveurs, au risque de payer 4 fois plus de puissance pour que les scripts aient une bonne marge et rattrapent leur éventuel retard sur un développement optimisé.
Mais il faut être honnête, un développement optimisé c'est ingérable pour des projets imposants. Si tu n'as pas un minimum de structure avec un framework par exemple, tu dépenses pas mal de fois plus de jours.homme. Je ne dis pas forcément au début du projet, dans ce cas c'est très simple, je parle déjà lorsqu'il faut mettre en place des fonctionnalités complexes sans avoir des librairies ou une structure de base, mais aussi en fin de projet ou en maintenance, quand il faut ajouter des fonctionnalités non prévus, patcher l'application, ou mettre à jour les procédures.
Donc il ne faut pas cracher sur les frameworks, on est tous conscients que cela coûte cher en performances, mais c'est tellement avantageux en terme de ressources humaines qu'il est irresponsable de passer outre pour des projets professionnels. Quand je vois comment cela se passe dans la boite où j'ai fait mon stage, sans framework, sans structure, cela fait peur…

[ouckileou]

1. Tout commence avec "Je n'ai pas besoin d'un framework."
2. Ensuite vous créez 7 classes.
3. Maintenant vous avez une petite librairie de classes.
4. Puis vous créez une application utilisant votre librairie.
5. Ça marche et c'est rapide, hourra!
6. Puis quelqu'un demande une extension à une fonctionnalité de votre application.
7. Et ils continuent à vous en demander plus, et plus, et plus, et plus...
8. Vous avez maintenant 43 classes.
9. Vous avez beaucoup appris lors des deux dernières années. Design patterns, sécurité, performance, tests...
10. Ce qui était une petite librairie est devenu un énorme, laid, non-testé, non-documenté, effrayant framework.
11. Puis vous changez de boulot.
12. Et vous créez à nouveau 7 classes...

Je ne sais pas si c'était le but à la base mais ce commentaire me parait être en faveur des frameworks, puisque :

1. Je pourrais m'en passer pour le moment mais je vais prendre un framework
2. Je récupère 150 classes mais bon elles ne sont pas toutes chargées
3. L'application grossit mais tout est bien organisé
4. J'ai tout un tas d'outils à dispo, pas besoin de tout réinventer
5. Je peux recruter des gens qui connaissent déjà, pas besoin de les former sur mon outil maison
6. etc etc

C'est curieux que si peu réagissent à ce type d'article.

Moi j'ai hésité, des fois c'est fatiguant d'avance de mettre le nez dans ce genre de débat...

Ça fait déjà un moment que Rasmus a dit que les frameworks, c'est bien ... pour ceux qui les écrivent. Il enfonce aujourd'hui le clou avec cette batterie de tests.

Oui enfin bon c'est pas parceque Rasmus le dit que c'est forcément vrai. Il a l'air de voir les choses par sa lorgnette de gars très technique, mais je sais pas s'il a les autres contraintes en tête des fois (ou alors il s'en fout). Les contraintes qui dirigent les projets en vrai.
Et là pour moi ça n'enfonce aucun clou, faire un benchmark sur un "Hello world" est ridicule et n'a rien de représentatif.
Puisqu'il évident que comme tu l'as dit, on s'adapte aux besoins et on ne prendra pas un framework pour faire ça.

Je crois que ça soulève un incontestable problème de méthodologie dans la programmation mais aussi un point peut-être plus grave : on essaye de tout faire avec PHP alors qu'en fin de compte on voudrait faire des choses pour lesquelles ce langage n'est pas approprié.

Un peu comme on a vu fleurir des sites Full-Flash lorsque ce type de média est apparu, puis du Full-Ajax lorsque les navigateurs se sont mis à supporter cette technique, on voit de plus en plus des applications en Full-PHP et... on va droit au casse-gueule, moins rapidement peut-être, mais on y va sûrement. Le sens de la mesure et des choix appropriés selon les besoins semblent absent trop souvent... Et puis j'ai l'impression (peut-être à tort notez bien) que certains s'ingénient à tenter de programmer en PHP de la même manière qu'on le fait en Java. Le résultat, ce sont des sites de plus en plus lourds... et lents. La programmation qui est derrière se veut hyper-professionelle avec des modélisations énormes, des framerowks testés et re-testés, des architectures super-évoluées... mais en oubliant des règles de bases de l'internet qui sont pourtant très loin d'être neuves et toujours d'actualité :
- l'internaute lambda est lent;
- l'internaute lambda est pressé.

C'est à partir de là que j'ai pas compris. Puisqu'on a toujours fait des sites full PHP non ? Un framework propose juste des outils pour ne pas tout refaire, et pour organiser les choses.
On part direct avec une architecture précise, c'est la seule différence. Mais on ne rajoute pas de fonctionnalités juste en utilisant un framework, on ne fait pas plus de choses avec ou sans framework, on les fait juste différement. Donc le parallèle avec le "full Flash" me paraît incongru. De même, je n'ai pas compris ce qu'était "la méthode de programmation en Java", puisque c'est pareil, les frameworks PHP ne proposent qu'une implémentation de divers pattern, principalement une architecture MVC, que nous avons tous encouragé à mettre en place sur ce forum. Utiliser un framework ne me parait pas être un problème de méthodologie, au contraire !

Il suffit de voir le nombre de messages sur ce forum avec des gens venant dire "j'essaie de mettre en place un modèle 3 couches mais j'ai un problème", ou autre chose de ce genre. Tous ces gens qui réinventent des trucs mais forcément pas aussi bien que plusieurs personnes qui se mettent en semble et laissent mûrir le truc. C'est déjà bien d'essayer mais ça a forcément ses limites.

À cet égard, un récent article de Nexen soulignait ce point : (source Nexen)

"La latence a un coût. Amazon a découvert que chaque 100ms de latence lui coûte 1% de ses ventes. Google a aussi remarqué que chaque .5 seconde de retard dans la génération des pages de résultats réduit son trafic de 20%. ".

ça c'est intéressant mais tout le monde n'est pas Google ou Amazon. Pour un tas de boite l'utilisation d'un framework n'aura pas de telles conséquences, le ralentissement sera imperceptible (si ralentissement il y a) mais les gains en terme de temps de développement, de maintenance, et de robustesse du code seront énormes, comme l'a dit Sekiltoyai dont le message résume tout.

[doctorrock]

Pour ma part, j'aime l'équilibre, et il y a un équilibre partout , il suffit de le trouver ^^

je bosse sous Zend framework depuis 2 ans maintenant, et avec une bonne archi, bien pensée, bien pesée, un bon cache OPCode, une bonne BDD, etc... on arrive à avoir quand même des performances intéressantes ( certes moins bonnes qu'avec un code PHP brut, mais celui-ci aurait pris 25 fois plus de temps à être élaboré )

[Cyrano]

... on arrive à avoir quand même des performances intéressantes ( certes moins bonnes qu'avec un code PHP brut, mais celui-ci aurait pris 25 fois plus de temps à être élaboré )

Peut-on envisager dans un avenir plus ou moins rapproché la possibilité de voir des améliorations dans ces performances justement ?

J'ai déjà lu sur des flux RSS il n'y a pas si longtemps que les nouvelles versions de PHP amélioraient parfois notablement la vitesse d'exécution. Est-ce qu'on pourrait penser à d'autres manière d'aider à rendre l'utilisation de frameworks aussi rapide que "du PHP brut" ou avec une différence négligeable ?

[zeus]

A part a compiler les frameworks, je me demande comment faire

Ou alors, cette alternative est déjà possible avec les caches d'opcode. Par exemple, Symfony intègre déjà une gestion de APC pour afficher un log de ce qu'il a fait

[zeus]

Un autre benchmark est paru ce matin : http://paul-m-jones.com/?p=315
Et on se rend compte que le même test "Hello world !" donne des résultats complétements différents ...

Cette fois ci, la méthodologie est indiquée (http://paul-m-jones.com/blog/?p=238) et je trouve, encore une fois, que le test n'est pas optimal parce qu'il y a moyen de faire mieux pour Symfony ...

Une autre chose qui m'a choqué, c'est que du propre aveu de l'auteur, il manque la connaissance de certains framework. Comment optimiser un framework pour le production (ce qui intéressant pour ce genre de test) sans le connaître ?

[doctorrock]

Perso j'ai un script de compile du framework que je lance avant de lancer ma première requête Web.

Il est possible d'améliorer les perfs, certes, on bosse sur l'autoload actuellement dans ZF, mais on ne pourra jamais rattraper PHP lui-même