En préambule je dirais que je n'affiche que mon intime conviction à travers cet article et mon expérience d'un an et demi de mise en application d'une solution à base d'EzPublish sur 4 grands sites totalisant environ 100.000 visiteurs uniques par jour.
J'étais tout d abord chef de projet sur un des projets puis ensuite responsable du département qui gérait l'ensemble des développements techniques liés à ces sites.
Ma première décision en tant que "nouveau" responsable du département fût d'arrêter les développements sous EZPublish.
Nous avions refondu tout nos sites sous un framework basé sur eZpublish en version "cluster". Il s'agissait de la version 3.8 mais il semble que la dernière version 4.0 présente des similarités.
Après un an et demi, nous avons donc décidé d'abandonner les solutions EzPublish pour nos sites et de refaire l'ensemble des sites eZpublish sous d'autres technologies dont je vous parlerai dans un nouveau post.
En voici les raisons :
La structure "macro" d'eZpublish :
Ce qui lui donne sa souplesse fonctionnelle lui enlève une percussion technique. En effet la structure de donnée d'EZpublish induit de multiples jointures SQL pour accèder à des éléments simples comme les titres ou chapeau...ou body d'un article. Pour pouvoir sortir ces éléments c'est parfois jusqu'à 7 tables qu'il faut mettre en action. Le résultat est la production de requêtes SQL très lourdes pour le serveur de Base de donnée.
La construction automatique des requêtes SQL:
Le moteur eZpublish produit automatiquement un certain nombre de requetes SQL avec les données que vous lui fournissez. Elles ne sont pas optimisées. En mettant en place un simple debug sur la première page dès son installation vous verrez que parfois nous avons des requetes de plusieurs pages pour la complexité d'un blog.
L'atomisation du système de cache:
EZpublish fragmente son systéme de cache. Ce qui parait séduisant au début devient vite un cauchemard de programmation car les blocks ou les vues ne décachent pas tous en maintenant. Vous avez donc des "pics de décachage" qui induisent la "reproduction des templates".
eZpublish ré-invente la compilation en PHP :
Au moment où vous "décachez"....misère car le moteur eZpublish va processer un language de template qui va reproduire des scripts PHP. Ce langage de template est en texte...non optimisé et non compilé. PHP va donc s'amuser à processer des fichiers textes pour reproduire des fichiers PHP.
Tout le monde sait bien que PHP est très à l'aise avec ces manipulations géantes de chaine de caractère (c'est une plaisanterie le langage n'est pas fait pour ça contrairement à PERL).
Bref dès que vous produisez du cache, les serveurs frontaux en bi quad core 3.8 ghz montaient à 100% de leur capacité pour la home..ralentissant toute la plateforme.
Notons qu'à chaque modification même infime d'un template il faut "le recompiler" à savoir se logguer sur le serveur en SSH...passez sa commande et attendre. Si vous avez plusieurs serveurs...cela devient un bel enfer.
du SQUID ou du VARNISH (quelque chose comme ça) tu mettras :
Les défaillances énoncées plus haut aménent plusieurs conséquences : nous avons été dans l'obligation de poser des SQUIDs devant nos 4 frontaux bi quad core doublés de 4 bases de données "costaud" pour simplement pouvoir mettre en ligne nos sites.
Là les pages avec du dynamique deviennent une horreur à gérer tant les problématiques de "surcachage" sont nombreuses entre les 3 ou 4 niveaux de cache eZ (même les fichiers de configuration ont du cache) et le SQUID devant.
Ton systéme deviendra difficilement maintenable :
eZpublish base sa pub sur sa souplesse. C'est certainement vrai ....mais par contre c'est guère prévu pour un site dèja en production.
Pour avoir essayer à plusieurs reprises d'ajouter à la volée des éléments dans une classe (à savoir par exemple un champs téléphone dans une classe "utilisateur)...c'est l'enfer car eZpublish va devoir reprocesser tout ce que vous avez déja mis en base de donnée pour transformer ces entrées pour chacun des éléments déja entrés avec la "vieille" classe.
Ces opérations sur des dizaines de milliers d'article laissent le bon vieux back d'EzPublish en rade grâce au bon PHP....
Il reste à utiliser une rustine non officielle d'EzPublish qui fait le boulot avec parfois quelques surprises
:)
Ajoutez à cela, l'explosion des fichiers de configuration "ini" qui sont légions et qui doivent être aussi recompilés....
Clou sur le gâteau : dans les fichiers ini des Ids de table sont mises en durs pour pouvoir faire fonctionner l'ensemble donc vous oubliez la possibilité de les faire passer de vos environnements de dev à une recette puis à une qualité....ces ini sont propres à chaque environnement et modifiables à la main à chaque fois après avoir été cherché dans la base de donnée support le bon ID de la bonne classe ou de la bonne vue.
Conclusion :
En 7 ans d'expérience sur des projets internet, j'ai vécu le cauchemard de ma vie avec ce CMS.
Pour moi, rien n'est y bien "pensé" au niveau technique.
Le temps de chargement de nos page était lent(10 secondes) en front office et affreusement lent (>30 secondes parfois ) en back office avec des plantages fréquents lors des transactions impliquant une perte des données en cours de stockage.
La solution de cluster imposant à l'époque (je crois qu'ils ont modifié maintenant) de toute mettre en base de donnée (binaire et data) nous a posé des problèmes de maintenance insolubles.
Pour terminer, le temps de développement est supérieur car en local nos développeurs sur nos serveurs étaient obligés d'attendre plusieurs minutes parfois pour avoir le résultat de leurs tests.
Sachant que quand vous programmez vous faites ce type de vérification fréquemment, je vous laisse imaginer la perte de temps liée.
Au final, la mise en place d'un framework basé sur une solution eZpublish a été un échec technique et commercial cuisant pour nous.
Hormis un choix malheureux de prestataire(s) 'peu performant(s)' dans notre cas, je suis persuadé que la solution EzPublish est structurellement défaillante pour des sites à fort traffic.
eZpublish peut faire tourner un blog comme n'importe quel autre CMS voir un site 'vitrine' (corporate par exemple) mais guère plus.
La solution eZpublish a gravement marqué les esprits "digitaux" au sein de notre entreprise et nous a poussé à développer de nouvelles approches dont je vous parlerai bientôt :
Approches liant économie de couts et efficacité de mise en oeuvre des solutions techniques.
Attention la version mise en oeuvre était eZpublish 3.8. De plus un Framework avait été posé devant masquant ainsi une partie des fonctionnalités natives d'eZpublish. Les éléments doivent donc être validés avec la dernière version d'EzPublish 4.0 que nous n'avons pas testé
100% d'accord avec votre analyse. Drupal offre l'avantage de pouvoir se concentrer sur le développement de fonctionnalités supplémentaires plutôt que de passer tout son énergie sur les bases de dev. et EZpublish demande une formation au départ alors que drupal est ouvert aux novices.
Sandrine
solaire
Bonjour,
Je suis en accord avec vous. La gestion de gros projets avec une solution eZ Publish apporte énormément de problèmes, de Plus travaillant aujourd'hui sur de gros site en qualité de développeur, le développement et très retarder par le fonctionnement d'eZ.
Je donnerai tout de même un avis plus favorable à eZ pour la création et la gestion de petits et moyen site web comme des facade de com pour les PME/PMI ou des site perso.
>un Framework avait été posé devant
>masquant ainsi une partie des >fonctionnalités natives d'eZpublish
Un framework maison ? un framework opensource ?
J’aimerais avoir des informations sur le framework posé devant. Si il surcharge la gestion de cache de eZpublish on peux difficilement blâmer ce dernier d’être peu performant.
L'utilisation de Varnish n'est pas possible car il ne prend pas en compte les instructions de cache des headers http si la page en question produit un cookies. Or eZpublish produit une cookies d'identification pour chaque connexion même anonyme.
Karles
http://www.karlesnine.com/spip.php?article153
J'ai oublié de vous demander avec quel CMS vous avez redéveloppé vos sites ? et si maintenant les problèmes de perf sont résolus ?
Envisageant de choisir EZpublish pour un site à 200.000 hits par jour, je suis effrayé par votre comment, pouvez-vous me dire quels étaient les sites sur lesquels vous avez eu ces problemes ? + quelle était le framework en frontal d'EZpublish.
Avec mes remerciements
Nous avons utilisé eZpublish sur des gros sites (40.000 visiteurs uniques par jour x 2).
Les performances ont toujours été lamentables malgré la mise en place de SQUID devant.
Je ne recommanderai pas eZpublish pour des sites à fort volume.
De plus attention à la version Cluster qui à l'époque (2007) était mal pensée.
Nous avons changer pour DRUPAL.
Vous pouvez voir les premiers sites sous DRUPAL fait par Edipresse ici :
http://www.femina.ch
et
http://www.lesquotidiennes.com
Les soucis de perf ont été résolu.
Pour www.femina.ch peut-être, mais pour http://www.lesquotidiennes.com/ c'est d'une lenteur exaspérante.
Et si le problème était ailleurs?
Vous pouvez maintenant y retourner...c'était uniquement dû aux blocks de remontée RSS sur la colonne de droite "qui attendaient" en fait d'avoir les flux RSS considérés et retardaient donc le chargement de la page.
Pour le reste vous avez la grosse explication au dessus sur pourquoi eZpublish est un "solubléme" et Drupal "une solution logicielle".
En effet les performances sur LesQuotidiennes.com ne sont pas bonnes. Le trafic des Quotidienne a quadruplé depuis son lancement.
Les faibles performances sont avant tout liées à des problématiques systèmes car le serveur sur lequel est LesQuotidiennes est hébergé maintenant est complétement "surchargé" car nous y avons beaucoup de site...il supporte environ 40.000 visites uniques par jour actuellement avec un taux de charge moyen "très élevé".
De plus, il s'agissait de nos premiers sites sous Drupal (comme la date de mon post au dessus le montre) et nous apprenions aussi avec quelques erreurs à la clé. Nous sommes en train d'en corriger certaines.
Après nous avons eu de très gros site en comparaison des Quotidiennes qui ont eu des performances "impressionnantes" en terme de temps de chargement des pages c'est à dire proche de la seconde pour des internautes suisses comme :
http://www.tdg.ch
http://www.24heures.ch
Qui ont, eux, des performances au dessous des 1.5 secondes "technique" de chargement de la page. Graph IP LABEL (http://www.ip-label) à l'appui.
nous avons encore quelques soucis avec LeMatin.ch par moment (quelques minutes dans la journée de ralentissement) :
http://www.lematin.ch
mais qui est simplement du au fait que nous n'avons qu'une seule et unique base de donnée pour 100.000 visites par jour et 500.000 pages vues...le reste du temps c'est à dire 99.5% du temps les performances mesurées avec IP LABEL sont inférieures à 2 secondes de chargement pour les internautes suisses.
Pour eZPublish c'est structurel....de nombreux posts dans de nombreux forums font état de problématiques structurelles de charge quasi-insolubles sauf à dépenser des sommes extravagantes en rustine (reverse proxy à la Varnish en particulier) ou solutions de cluster défaillante (deux pauvres tables qui prennent tout).
Pour information la plateforme Le Matin - TDG - 24H a pu doubler son audience en sortant d'eZpublish. Nous accueillons actuellement plus de 220.000 visites par jour (pour les 3) pour 1 millions de pages vues par jour sans aucun reverse proxy (varnish ou squid) devant servant le cache avec des caches à 3 ou 5 minutes suivant les sites avec une puissance équivalente à notre infrastructure avec eZpublish qui tolérait "très mal" environ 500.000 pages vues par jour avec l'utilisation de 2 reverses proxys "squid" en frontal en plus.
Pour résumer, La différence entre nos installations DRUPAL et eZPUBLISH :
))) DRUPAL EN MARS 2009 avec 1 an d'expérience derriére
Avec DRUPAL sur TDG (http://www.tdg.ch), 24H (http://www.24heures.ch), Le Matin (http://www.lematin.ch):
+ Nombre de pages vues par jour : 1 millions
+ Temps moyen de chargement des pages : 1.5 - 2 secondes
+ Nombre de serveurs applicatifs : 9 sans aucun reverse proxy (ni SQUID, ni VARNISH) avec 2 bases de donnée.
+ Intervention en urgence par mois : nulle
+ Nombre de développeurs nécessaires produire et faire tourner les sites : 2
))) EZPUBLISH en 2007 et 2008 avec 1 an d'expérience :
+ Nombre de pages vues par jour : 600.000
+ Temps moyen de chargement des pages : entre 5 et 10 secondes
+ Nombre de serveurs applicatifs : 10 avec 2 reverses proxys SQUID et 4 bases de données.
+ Intervention en urgence par mois : une dizaine de nuit et en week end pour refaire partir les site suite à une montée en charge non controllable des front.
+ Nombre de développeurs nécessaire pour produire et faire tourner les sites : entre 10 et 12
Très honnétement d'un simple point de vue "business" il n'y a pas photos.
D'un point de vue "technique" la différence entre les 2 est un abysse technique.