l’enfer de J.Duvivier
Pierre Jean Duvivier, responsable du département WebFactory de EditPress reviens sur son expérience avec Ez Publish 3.x et ces raisons de son abandon par EdiPress.
Je le cite : En 7 ans d’expérience sur des projets internet, j’ai vécu le cauchemard de ma vie avec ce CMS.
Il explique bien les difficultés de eZ publish pour les sites web à forte audience. J’aime bien son expression pics de décachage qui correspond au tempête SQL que je rencontre et qui génère des lock de table en chaine avec l’utilisation du mode cluster de eZ 3.x. J’ai évoqué le sujet chez pwet sur son article à propose du eZ developer day à Paris le 17/04/2008
Je vous invite a en lire plus sur cette expérience de Ez publish pour des sites web média à fort trafic.
Sa seul modération pour Ezpublish est le suivante : 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 d’eZpublish.
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.
Ma vision de la Problématique
Avoir un site hyper-réactif, au contenue dynamique, aux mises à jour quasi immédiate impose un partage d’information tout aussi immédiat, avec une information vivante et volatile impose la centralisation de cette information. Toute tentative de répartissions, de distribution engendre une latence, un besoin de contrôle et de vérification de cohérence, bref tout ce qui engendre du délais et donc le contraire de l’hyper-réactif.
Quelque exemple d’hyper-réactivité d’un site : 
Nombre de commentaire à jour pour chaque article sur la home page Commentaire immédiatement disponible Liste des articles de première page annoncé sur chaque pas d’un site Personnalisation a outrance (login, avatar, message interne etc..)
En conséquence que cette information ultra centralisé soit accessible entre un nombre de frontaux ou processus important engendre de façon exponentiel à l’audience des accès concurrentiel et conflictuel à la même information. On arrive à un point de l’état de l’art informatique qui n’est pas encore résolut de façon économique.
Mon expérience ce porte sur des sites eZpublish 3.9 et 3.10, hyper-réactif, qui impose l’utilisation d’ajax pour individualisé le contenu de chaque page ou presque, ceci quasiment en temps réel. Ces sites génère 7Millions de pages vues et 1 millions de visiteur unique par mois.
Dans le cas d’un site eZ avec du contenu dynamique la limite technique est de 30000 VU / 24h avec le partage d’information via NFS. Au delà de cette limite différent « bug » apparaisse qui vienne défigurer le contenue du site (bug wilcard, Bug NULLNULL, Perte cache block)
Dans le cas d’un site eZ avec du contenu dynamique la limite technique est de 35000 VU / 24h avec le partage d’information via le mode cluster dans une base de donnée Innodb/Mysql. Au delà de cette limite les demandes d’accès exclusif au information trop nombreux au point de bloqué le fonctionnement de l’application.
A ce seuil technique d’utilisation de eZ comme générateur de site web eZ publish n’a pas de réponse fiable et viable à 100%. La préconisation de eZ Publish, information recueillie au eZ Developper day Paris 2008 et confirmée a l‘Ez Conférence de Skien 2008 est l’utilisation d’un NAS dont le ticket d’entré est de 35K€ (plus les cout de maintenance et administration annuel). C’est cette solution qui a semble avoir été mise en œuvre par d’autre acteur de la presse pour leur sites web atteignant le seuil technique des 30 ou 35 Kvu /24h
Et encore, l’utilisation d’un NAS offre que plus de puissance et donc traitant le partage d’information plus rapidement diminue les risques de conflit d’accès sans pour autant l’éliminer. En effet un NAS partage l’information via des protocoles n’offrant pas l’exclusivité d’accès au fichier (NFS, SMB etc). En outre l’utilisation d’un NAS introduit un goulot d’étranglement dans l’architecture. En cas de défaillance de celui ci tout les sites web l’utilisant seront impacté.
L’opposer d’un contenu dynamique c’est le site statique. C’est justement la solution avancé par pwet sur le blog de smile dans l’article : eZ publish à très hautes performances.