Qu’est-ce qu’on fait ce soir ?
Il y a quelques temps, j’ai lancé le site Qu’est-ce qu’on fait ce soir ? sous eZ Publish 4.2.0, développé en 3/4 jours, puisque le concept est relativement simple, donc des classes de contenu très simples aussi : catégorie, idée, commentaire.
J’avais un compte hébergement mutualisé chez OVH, lorsque j’ai mis en ligne le site, je me suis rendu compte que le site ramait pas mal, malgré une optimisation poussée des caches eZ Publish.
C’est là qu’on se rend compte qu’eZ Publish, quelque soit la version, requiert pas mal de ressources serveur, comparé à d’autres CMS (Drupal, Typo3, WordPress, SPIP, …). J’ai donc redéveloppé le site en PHP 5 pur, en 2 soirées. Et c’est là qu’on se dit qu’eZ Publish n’est pas forcément la solution adaptée à tout type de site, charge ou pas charge. Je connais des sites développé sous SPIP, multilingue, multisites, qui tiennent très bien la route, des WordPress utilisé en CMS, etc… Donc avant de se lancer sous eZ Publish parce qu’on dit que c’est LE CMS du moment, il faut y réfléchir à 2 fois. L’inverse aussi d’ailleurs; lorsqu’on commence à développer sous WordPress pour un blog avec des fonctionnalités avancées (besoin de plus que d’articles et de catégories), on regrette eZ Publish et la facilité de créer tout type de contenu.
Même si je suis fervent développeur eZ Publish, je pense qu’il lui reste des faiblesses, comme tout CMS d’ailleurs, mais des faiblesses qui restent depuis le début (j’ai commencé sous eZ 3.6), les mêmes : sa lourdeur…
A bon entendeur !
Tags : CMS, drupal, eZ Publish, SPIP, typo3, Wordpress + Catégories : eZ Publish, PHP, Web, Wordpress
eZ Publish tourne encore difficilement sur du mutualisé, surtout si les ressources sont assez restreintes. Ce n’est pas forcémenet la cible initiale, mais ce serait un plus sympathique. Un allègement du noyau et la possibilité de désactiver certaines des fonctionnalités pourrait aider en ce sens.
Avez vous jeté un oeil à ceci en redévelopant « from scratch » : http://ezcomponents.org/docs/tutorials/MvcTools ? Permet de dérouler des applications en 2 temps 3 mouvements. D’ailleurs une application exemple, similaire au plan fonctionnel à twitter, est disponible : http://svn.ez.no/svn/ezcomponents/docs/examples/applications/TheWire/. Le concept ne me semble pas forcément très très éloigné de celui de http://questcequonfaitcesoir.fr/, à première vue.
Bon blogging !
Ca fait toujours un peu ch… de lire ça, mais principalement parce que c’est la vérité. Ce défaut est là depuis longtemps, effectivement, et c’est un de ceux qui me gênent le plus, pour pas mal de raisons.
Sache par contre que ce n’est pas comme si nous considérions que ce n’est pas gênant. Au contraire même. Maintenant, je ne vais pas te dire que ce sera corrigé demain… si c’était possible, ça se saurait, pour commencer.
En conclusion, si le problème de lourdeur est réglé, tu veux bien dire qu’eZ remplace les autres outils ? ;)
Votre commentaire *C’est vraie que eZ est lourds, il y a quelques temps j’ai été amené à faire un benchmark entre deux sites un sous eZ, un sous Drupal, fonctionnellement identique, un scénario de test basé uniquement sur de l’affichage de contenu bilan: à 40 sessions concurrente le serveur s’écroule, cpu à 100% pour ez, sous drupal, 100 sessions concurrente la machine bronchait pas, on pourrai, avec un rab de mémoire monter à 200 sessions, voir plus.
Maintenant je n’ai pas eu le temps de regarder les bottlenecks coté ez,donc je sais pas trop quel est le problème, bertrand?
On peut voir les choses selon 2 angles :
Optimiser eZ Publish :
——————————–
S’il s’agit d’optimiser eZ Publish « out of the box » par optimisation d’algorythmes, de SQL, d’accès aux filesystem ou autres mécanismes ne dégradant pas le fonctionnel et la productivité de développement : GO. Et sur cet aspect, chaque version améliore un peu l’existant, mais les grosses optimisations nécessiteraient sûrement des modifications majeures et impactantes (moins de surcharges, remplacer le SQL par autre chose…)
S’il s’agit d’optimiser eZ Publish en dégradant le fonctionnel : NOGO
Choisir la bonne solution pour chaque projet :
—————————————————————-
Dans le cas du site en question, hébergé sur un mutualisé, je dirais :
- Piste 1 : PHP maison, avec un FrameWork léger (type COPIX par exemple)
- Piste 2 : Un CMS léger, ou un Blog, type Drupal ou DotClear
- Piste 3 : eZ Publish, dans l’optique d’un hébergement dédié, et dans la perspective d’ajouter progressivement d’autres briques fonctionnelles.
eZ demande beaucoup au système. Il demande tellement qu’il n’est pas possible de distingué système et application dans la conception. Vous devez obligatoirement pour un obtenir le meilleur travailler le CMS comme le système et réseau en synergie. L’optimisation des caches block par exemple doit être réfléchi avec en tenant compte des I/O, du cache binaire php, de l’optimisation innodb de la base de donnée etc…
J’ai longuement présenté les optimisations des caches web et des reverse proxy sur mon blog.
Karles
@ Bertrand : nous sommes d’accord, bien que depuis le début, les choses se sont améliorées, mais on sait que dans la bataille des CMS, à chaque fois que j’en parle à un autre développeur, il me répond que eZ c’est nul parce que c’est trop lourd…
@ Sylvain : en fait une installation eZ Publish par défaut nécessite quelques reconfigurations INI, je pense que celles définies par défaut ne sont pas viables pour mettre en production. Le fonctionnel du site y compte pour beaucoup, notamment pour la gestion du vidage de cache de contenus.
@ Gandbox / Karles : en fait je parle surtout de mon point de vue, en tant que Développeur. Je travaille en agence web, et le temps compte beaucoup. On n’a pas forcément la possibilité de travailler directement avec un sysadmin connaissant eZ Publish, ou voire même on travaille avec un hébergeur dont la configuration serveur est opaque. Je n’ai pas non plus des connaissances expertes en administration système. Par contre ce que je sais, c’est qu’il est nécessaire sur eZ, de travailler sur l’optimisation de l’installation jusqu’à la mise en production, du système de fichiers, des serveurs, de toute la configuration INI (caches), etc…