Consultez la FAQ sur le ZF avant de poster une question
Vous n'êtes pas identifié.
Pages: 1
Bonsoir,
Je n'ai pas assez pratiqué Zend en Prod pour répondre moi-même à cette question
La charge est-elle vraiment plus importante quand on utilise MVC et les controlleurs ?
Je m'explique :
Aujourd'hui je n'utilise les MVC que pour des applications d'administrations ou de services-clients.
En ce qui concerne un site internet, j'utilise un fichier de routage perso qui en fonction du REDIRECT_URL, vas chercher le layout approprié et inclut dans ce layout la page concernée. (très proche de MVC donc, mon fichier de routage est un gros controller qui en fonction de l'action, le redirect_url, renseigne les bonnes infos, avec un bon gros include à la fin)
Avec mon graphiste, on ne conçoit que des sites avec (si possible) deux constructions (layouts) différentes au maximum, une pour l'accueil et une pour les pages de contenu (classique donc).
Mon arbo est similaire à celle utilisée dans le modèle MVC. Dans mon fichier de routage j'ai un gros switch qui renseigne une variable pour le layout, une pour le contenu (script), et d'autres pour le reste (meta, traitements particuliers), fait un include du layout au final, qui lui-même inclut toutes les parties de la structure du site : header, footer, menu, + le contenu de la page demandée.
Arrivée à ce stade, je me demande si ce n'est pas plus idéal d'activer systématiquement MVC et d'utiliser un frontController, ce qui est quand même plus propre.
Mais voilà, en terme de performances, y-a-t'il une réelle différence ?
Merci.
A+ Benjamin.
Dernière modification par Delprog (13-10-2008 17:05:08)
Hors ligne
Bonjour,
Oui, il y a une réelle différence, (beaucoup de fichiers inclus, beaucoup de traitements supplémentaires).
Cependant il faut avoir beaucoup de trafic et peu d'activité en base pour s'en rendre compte. Sur mes gros sites, le problèmes de performances ne sont quasiment jamais venus de PHP. Ils sont quasiment toujours venus de la base de données (le seul cas où PHP m'a posé des problèmes, c'était sur du traitement d'images...)
Bref, à moins que tu aies un trafic de fou et un site simple (genre un blog avec énormément de trafic), tu peux utiliser le MVC sans scrupule, à mon avis c'est pas lui qui sera bloquant...
A+, Philippe
PS: cette opinion est sujette à débat et dépend pas mal du type de site qu'on code...
Hors ligne
PS: cette opinion est sujette à débat et dépend pas mal du type de site qu'on code...
alors débattons un brin
Non, je plaisante, je ne polémiquerai pas. En tout cas pas avec Philippe, avec qui je suis complètement d'accord. On voir souvent passer des questions du type "est-ce que si j'utilise des guillemets doubles pour mes chaines les performances seront moins bonnes qu'avec des guillemets simples ?".
La question n'est pas idiote, et la réponse intéressante (faites le test ).
Mais ce qu'il ne faut pas perdre de vue, c'est que dans l'immense majorité des situations, les serveurs faisant tourner des sites ou applis en PHP pourraient intégrer une grille de super-calculateur quasi sans impacter les performances du site en question tant ses besoins propres sont dérisoires.
Si je puis donner un conseil, privilégier avec PHP toutes les ressources qu'ils vous offre pour écrire du code propre, facile à maintenir et à faire évoluer. Oubliez les problèmes de performances (j'ai bien dit pour PHP, car je suis également d'accord avec Philippe quand il dit les bases de données sont beaucoup plus problématiques).
Le jour où se posera vraiment cette question, il sera largement temps de trouver des réponses (refactorisation, déploiement d'un cluster, accélérateurs de code, systèmes de caches de contenus, etc.).
N'oubliez pas qu'à l'époque de PHP4, beaucoup moins performant que PHP5, alors que les serveurs disposaient de ressources matérielles également très largement inférieures à ce que l'on a aujourd'hui, des sites en PHP étaient déjà capables de supporter plusieurs millions de visites jours...
En un mot : oui aux frameworks, oui aux classes de haut-niveau, oui à tout ce qui rendra votre code plus propre ! La chasse aux millisecondes, vous verrez ça le moment venu
PS : il vous suffira de consulter l'historique de charge de vos serveurs pour constater que je n'invente rien
Hors ligne
Personnellement, je suis d'accord avec Philippe et Gauthier. Je lisais récemment aussi (mais je ne sais plus où) qu'aujourd'hui il est bien moins onéreux de rajouter un ou plusieurs serveurs ou de glonfler les caractérisques d'un serveur pour étaler une montée en charge plutôt que de refactoriser. Cela ne veut pas dire évidemment qu'il faut coder sans réfléchir ou sans commenter son code ou sans le structurer, mais cela indique tout de même qu'il y a un juste milieu à atteindre dans la recherche de performances.
Coder propre, utile, fonctionnel, réutilisable et agréable OUI ! En faire une obsession NON !
Je pense aussi que si l'on travaille avec le Zend Framework, une bonne habitude à prendre (pas toujours facile de changer des habitudes...) c'est d'adopter les conventions de codage proposées par Zend.
++
Hors ligne
Pages: 1