Submitted by Pierre Jean Duvivier on Sun, 03/08/2009 - 11:57
Il y a 18 mois nous décidions de massivement migrer d'eZpublish vers Drupal. Nous avions 6 sites sous eZpublish (notre Intranet, le Corporate - http://www.edipresse.com) mais surtout nos sites majeurs : LeMatin (http://www.lematin.ch), La Tribune de Genève (www.tdg.ch) et le quotidien vaudois 24heures.ch (http://www.24heures.ch).
Femina (http://www.femina.ch) complétait la liste.
Les plus gros sites à savoir LeMatin, La Tribune de Genève et 24 heures ont tous migré vers Drupal. TDG et 24 heures en septembre 2008, LeMatin.ch en décembre 2008, Femina en Janvier 2008 (premier site sous Drupal). Nous avons conservé sous eZpublish l'intranet et le corporate.
L'ensemble des 3 premiers sites représentaient environ 500.000 pages vues par jour en début 2008 et en représente maintenant le double à savoir 1.000.000 de pages vues un an et demi après.
18 mois après...quel bilan final pouvons-nous tirer de cette expérience ?
1 - La défaillance architecturale au niveau applicatif d'EZpublish est clairement démontrée et ne fait plus aucun doute.
Infrastructure sous EzPublish
Nous avions tout les difficultés du monde en 2008 à maintenir une plateforme sous Ezpublish à 500.000 pages vues par jour comprenant :
- 2 squid en mode reverse proxy
- 4 frontaux qui accueillaient les visiteurs
- 4 bases de donnée.
- 1 serveur de cron
soit 11 serveurs servant 500.000 pages vues par jour environ.
Pour ces 500.000 pages vues, nous avions besoin de 10 développeurs en mode maintenance (et en régie !!) pour assurer un quotidien pénible avec de nombreux problèmes de mises à jour et "explosion de base".
La moyenne du temps de chargement des pages se situait entre 5 et 15 secondes selon les pages et les sites avec des pages qui mettaient parfois un temps infini à se charger.
Les temps d'accès dans le back office de nos applications étaient excessivement longs et nos journalistes complètement désespérés devant des performances aussi médiocres.
Moi et mon collègue assurions des dépannages nocturnes et de week end 3 à 4 fois par mois.
Au début septembre 2007, nous étions épuisés par un "solubléme" : un solution logicielle qui crée plus de problèmes qu'elle n'en résout.
Infrastructure sous DRUPAL
En Mars 2009, après la migrations sous Drupal pour le même nombre de site et des serveurs équivalents, nous avons :
- 7 serveurs frontaux
- 2 bases de données
soit 9 serveurs servant 1.000.000 de pages vues par jour. Nous avons pu faire tourner 400.000 pages vues sur 3 serveurs pendant plusieurs mois sans aucun problème.
Pour ces 1.000.000 de pages vues, nous avons besoin de 1 développeur en mode maintenance (à l'interne) pour assurer un quotidien sans aucun problème particulier. Nous n'effectuons quasi aucune intervention nocturne ou de week end (1 tout les 2 mois en moyenne).
La moyenne du temps de chargement des pages tourne entre 1 et 5 secondes soit 3 fois moins en moyenne que leur équivalent eZpublish avec 2 fois moins de trafic.
Au final la plateforme sous DRUPAL avec 2 fois plus de pages vues et un peu moins de serveurs nécessite 10 fois moins de ressource de développement pour des performances nettement supérieures
Entre EzPublish et Drupal, ce n'est plus un KO comme le titrait un billet précédent mais simplement deux mondes différents....
Pour moi, eZpublish n'est pas fait pour faire tourner des sites media à fort trafic offrant un rafraichissement important de l'information et une nécessité de mettre en ligne "immédiatement" certains types de contenu.
Il peut faire ce que font tout les CMS à savoir un site vitrine (style corporate et encore isolé sur un seul serveur complétement dedié) et un blog sans aucun trafic.
quelques notes, ou autres versions de l'article ou encore d'autres articles qui alimentent le débat
Un article intéressant qui compare différent CMS :
http://www.r-geek.com/2009/01/27/cms-jungle-drupal-joomla-ezpublish-typo...
Un autre article concernant eZpublish trés documenté :
http://pwet.fr/blog/les_performances_d_ez_publish
L'article d'un utilisateur ayant aussi choisi Drupal après eZpublish :
http://www.webexplorateur.com/2008/07/lenfer-du-choix-dune-solution-tech...
où je vous conseille vivement de lire les commentaires aussi.
For other people who don't know what French it is :
The English version of this story is here:
http://www.media-business.biz/content/ezpublish-cms-drupal-cms-2-years-e...
Se puede leer este en Castellano aqui:
http://www.media-business.biz/content/con-ezpublish-y-drupal-2-anos-de-e...
Bonjour,
J’apprends ce matin dans le cadre d’une formation Drupal que EDIPRESS abandonnait Drupal pour un autre outil CMS !
Qu’en est-il ?
Meilleurs messages
FDG
Bonjour,
La personne qui vous en a parlé est mal renseignée. Nous n'abandonnons pas Drupal.
Cordialement.
Bonjour,
est-ce que les sections de petites annonces du groupe Edipresse sont également développées avec Drupal?
merci!
Non elles sont actuellement développées sous un couple ASP/Oracle. Nous devons en changer cette année..
Bonjour
Pourriez-vous précisez si les sites repris sous Drupal adressaient le même périmètre fonctionnel? De ce que je connais du contexte, il avait été prévu de réaliser un Back Office user friendly qui permettait par de simples drag n drop de construire le rendu du site.
cette fonctionnalité a t'elle été conservée avec Drupal?
Bonjour,
Les fonctionnalités étaient strictement les mêmes au départ que sous eZpublish. Nous n'avons pas eu de pertes fonctionnelles. Par la suite, les fonctionnalités se sont enrichies.
Le plus grand reproche que nous faisaient nos journalistes et webmasters de site était la lenteur exaspérante du back office "ezpublish" qui n'avait plus rien de friendly et l'absence de stabilité globale de l'application. Pour que nos lecteurs comprennent bien "ces ralentissements", on avait des pages qui mettaient plus de 300 secondes pour se sauvegarder en back office....
En passant à Drupal, la rapidité était (très) nettement supérieure et la stabilité excellente ce qui ne veut pas dire qu'il n'y ait de problématiques à traiter...
Cordialement.
Bonjour, Je trouve ce comparatif tout à fait dangereux.
Il est évident que "Out of the Box" Drupal est plus rapide que eZ Publish, puisqu'il contient moins de couches logiques. A ce petit jeu on pourrait également pousser la comparaison entre eZ Publish et du Perl, ou entre du JAVA et du C++. Il est également évident que les performances sont presque exclusivement dépendantes de la qualité de la conception, du développement, de l'optimisation du cache et des infras. Et comme vous ne pourrez jamais démontrer qu'il n'existe pas un défaut d'exploitation de l'outil (à part de publier le code ?), autant ne pas publier de billet "polémique" basé sur une expérience malheureuse et non généralisable, qui par ailleurs discrédite le travail de nombreux développeurs, et peut inquiéter à tort de nombreux décideurs.
Pour information, il existe des expériences inverses, à savoir des migrations de Drupal vers eZ Publish, pour ces même raisons de performances (et de faiblesses fonctionnelles). Il est "étonnant" de constater qu'une mauvaise utilisation de Drupal provoque le même phénomène...
Par ailleurs, je suis content que tout soit rentré dans l'ordre avec l'utilisation de Drupal, qui tout comme eZ Publish est un très bon outil lorsqu'il est correctement exploité. D'ailleurs puisque le périmètre fonctionnel de Drupal était suffisant pour couvrir vos besoins, c'était un meilleur choix qui ne nécessitait pas l'étape eZ Publish, et qui ne nécessitait donc pas de telles galères.
300s pour une sauvegarde en BO, soit le modèle de données est pourrie, soit y a un pb d'infra ou même les deux. Tout ne peut pas incomber à eZ Publish (même s'il n'aide pas forcément).
Sinon, rigolo de voir que l'on peut être notifié des réponses aux commentaires mais sans pouvoir mettre son Nom / Prénom / Email dans un quelconque champ.
Dommage que ce retour d'expérience soit trop imbibé de votre ressentiment à l'égard d'eZ Publish, il y perd en crédibilité je trouve.
Je pense également qu'un gros problème d'eZ Publish en France a été la sous estimation de la montée en compétence sur eZ Publish de la part des intégrateurs conduisant à des contre performances. Cela tend à se résoudre maintenant mais c'est clair que les premiers clients ont du payer le prix fort et essuyer les platres (en tant qu'ex de SSII, j'ai aussi essuyé les platres lors de projets se terminant mal faute notamment d'une maitrise suffisante de l'outil et d'une doc clairement insuffisante à l'époque (version 3.6 et 3.7).
....
Je ne rentrerai pas dans les détails du projet qui appartiennent aux sociétés qui ont été impliquées mais....nous avons pu tirer "mieux" et "plus" avec une surcouche devant EZpublish juste avant qu'on le jette à la poubelle avec de très bons ingénieurs issus d'une grosse société de service connue en France que je ne citerai pas ici.
Ce "mieux" et "plus" nous a permis de diviser les temps d'accès de 2 à 3 sur eZpublish malgré les lacunes "immenses" du modèle de donnée.
Pour information nous avons viré 2 prestataires auparavant parce qu'ils n'arrivaient pas à atteindre ces objectifs.
Le troisième a réussi "avec EzPublish" mais à quel prix...(au sens propre du terme).
Malgré ces 5 secondes de temps moyen de chargement hors période de charge importante (pic) étaient insuffisantes pour nous et nous avons décidé de changer de solution technique non sans avoir étudié une migration de la 3.8 à la 4.0 qui s'est révélé dans notre cas "particulier" assez problématique à opérer.
L'étude sur la 4.0 mené par "un de ses très bon ingénieurs" (payé cher..) "natif" a montré que la nouvelle version d'Ezpublish (à l'époque) était tout aussi une désastre sur le modèle de donnée que la 3.8 et nous apporterait le même lot de problème.
Je filtrerai qu'une seule info confidentielle..."en fin de vie", Ezpublish nous coutait pas moins de 60.000 EUROS de consulting par mois pour "simplement le maintenir en vie".