» Commentaires

- ....trés honnetement (#67685) par .....consultant le 21 Mars 2009 à 17:55

En effet eZpublish n'est pas forcement aussi "noir" que le dit le billet de media-biz-truc mais....

Pour être consultant dans une société qui l'utilise (en 3.8 et en 4.0) ...il y a quand même des grandes lacunes de conception sur le modèle de donnée qui est largement déficient pour les sites à haut trafic et haut "rafraichissement d'information".

Typiquement se taper plusieurs jointures lourdes (fait un debug eZ...) pour simplement reprendre un titre par exemple ou un attribut d'une classe "pose" problème.

Il y a eu certains gourous de ces architectures "macro" mais cela fonctionne "mal" au niveau technique...

EZpublish est surtout une réussite marketing pour un produit aussi "moyennement réussi" au niveau technique.

Tout ce qu'on peut faire avec eZpublish on peut le faire avec un autre CMS genre site vitrine (un wordpress suffit).

Perso je ne vois aucun intérêt sauf à vendre de la prestation de service.

Je devrais pas le dire vu que c'est ça qui me fait vivre mais bon.

Ps : la comparaison sur le billet de mediabiz truc est surtout une comparaison en terme "financiére"...

Autre chose pourquoi avoir besoin d'un reverse proxy (squid) pour apparemment 2 fois de trafic que sous Drupal sans proxy (d'après le billet).

bref...sinon super article et bien argumenté.

- Précisions (#67686) par Damien le 21 Mars 2009 à 18:44

Ce que vous appelez "lacunes techniques" est ce qui fait une grande force d'eZ Publish : la souplesse. C'est une question de point vue. Pour moi, le seul réel problème que ça pose est plus au niveau de la volumétrie qu'au niveau des perf. brutes.

"Tout ce qu'on peut faire avec eZpublish on peut le faire avec un autre CMS genre site vitrine (un wordpress suffit)."
il n'y a pas de réponse absolue, mais ce qui est sur c'est qu'on peut réellement faire un tas de chose avec eZ, et Wordpress que vous citez ne joue pas tout à fait dans la même court.

"Autre chose pourquoi avoir besoin d'un reverse proxy (squid) pour apparemment 2 fois de trafic que sous Drupal sans proxy (d'après le billet)."
Le reverse proxy est conseillé avec eZ Publish en mode cluster (peu importe le trafic en fait) pour éviter un stress inutile sur la base de données servant au cluster, si on peut également l'utiliser sur le reste, y'a pas de raison de s'en priver. D'ailleurs, je suis curieux de savoir comment est géré la problématique multi-frontal avec Drupal (médias uploadés dans le backoffice, éventuels caches, ...)

- Autre point pour la 4.1 (#67687) par Jérôme le 21 Mars 2009 à 20:42

Bonsoir Damien, un autre point qui pourrait t'intéresser aussi :

Pour la 4.1 nous avons eu une vraie volontée de limiter le nombre d'accès disques, le travail est toujours en cours, mais a déjà été assez bien avancé [1].

L'avantage de ce nouveau système, c'est qu'il utilise complètement le système d'autoload et on évite ainsi beaucoup d'appels à file_exists, limitant les i/o disques.

Je t'invite aussi à lire la documentation dans le fichier config.php-RECOMMENDED [2], particulièrement la constante EZP_INI_FILEMTIME_CHECK qui permet d'économiser pas mal d'i/o aussi au niveau des fichiers de settings.

En espérant que ça aide.

:)

1. http://issues.ez.no/14116
2. http://pubsvn.ez.no/nextgen/trunk/config.php-RECOMMENDED

- WP vs eZ... (#67688) par Nicolas Steinmetz le 22 Mars 2009 à 07:43

"Tout ce qu'on peut faire avec eZpublish on peut le faire avec un autre CMS genre site vitrine (un wordpress suffit)."

Que ce soit les sites Vélib (& dérivés) ou bien encore une application de gestion d'actifs forestiers que j'ai pu faire avec eZ Publish, je ne me les vois pas du tout faire avec Wordpress. Que WP couvre des besoins de CMS de base, je veux bien mais pour la partie "Content Management Framework", y a pas photo. D'ailleurs, même pour les deux applis mentionnées, je pense d'ailleurs que le faire avec un framework style Symfony aurait été plus judicieux en fait mais bon à l'époque Symfony n'existait pas / n'avait pas encore la visibilité qu"il a aujourd'hui...

Pour la flexibilité d'eZ, ce qui me gène surtout c'est la partie déploiement avec mise à jour des classes de contenu à faire "forcément" en back-office ou sinon à faire via l'import de packages (mais du coup, on peut perdre les contenus existants). Ce serait vraiment bien qu'on puisse faire des migrations d'objets via un script utilisant l'API eZ Publish... On éviterait les erreurs humaines lors des déploiements...

- Mise à jour des classes de contenus (#67689) par Jérôme le 22 Mars 2009 à 08:52

Nicolas :
Tu pourrais être intéressé par l'extenion eZXMLInstaller [1] on l'utilise pour certains projets, et dans mes souvenirs on a jamais rencontré de problème majeur.

Pour la réplication de contenu (push stagin -> prod par exemple), on peut éventuellement utiliser DataImport [2].

1. http://projects.ez.no/ezxmlinstaller
2. http://projects.ez.no/data_import

- 4.1 et livraisons (#67690) par Damien le 22 Mars 2009 à 11:48

@jerôme : oui j'ai suivi tout ça au fur et à mesure des commit dans le SVN :) ça ne peut pas faire de mal (surtout sous Windows...)

@nicolas : effectivement, la gestion des différents environnements et des livraisons est certainement un des points noirs du dev avec eZ Publish.

- Perfs eZPublish (#67691) par Maxime THOMAS le 22 Mars 2009 à 13:27

A mon grand regret, de nombreuses personnes tirent à boulets rouges sur eZPublish notamment à cause de ses performances. Cela va du simple développeur qui perd 5 secondes de sa vie à chaque F5 et au client qui se plaint du temps de chargement après publication d'un contenu.

Je profite que ce billet soit assez polémique pour faire la promotion d'eZPublish et dans les meilleurs termes qui soit puisque critiquer la conception logicielle du produit revient sans doute à dire que l'on a pas compris ce que les développeurs d'eZSystems voulaient faire. Une récente conversation avec Bertrand Dunogier à Barcelone m'avait permis de me rendre compte du processus assez complexe de test et de déploiement des versions d'eZ avant les releases officielles. En clair, on est loin d'un Joomla où on commite du code d'autres applis...

D'autre part, il vrai que mal configuré un eZ peut donner des performances désastreuses. Ce qu'il faut savoir c'est que l'outil en lui même ne fait pas tout, si vous ne disposez pas de connaissances suffisantes pour configurer un Apache ou un Squid (voire même Varnish), ou encore que les Entêtes HTTP sont pour vous un mystère, il faut sans doute se pencher un peu plus sur le fond du problème avant de taper sur le logiciel. Des articles existent sur ez.no ou encore sur les blogs remontés par planet ezpublish (fr or not), il faut un peu chercher c'est tout.

Donc pour résumer, c'est comme d'hab, on hésite entre un PEBCAK et un RTFM.

- "L'outil en lui même ne fait pas tout !" (#67692) par Plopix le 22 Mars 2009 à 18:50

C'est tellement vrai !
Je me souviens de mon prof de Tennis qui me disait de ne pas me plaindre de la qualité de ma raquette que c'était le bonhomme qu'il fallait changer...

Je pense que la plupart des personnes qui tirent sur eZ Publish n'ont pas pris la peine de faire des recherches vraiment approfondies ou ne l'ont pas utilisé dans un vrai projet conséquent.

C'est certain qu'eZ a des problèmes de performances(qui se réduisent à chaque nouvelle version) si on se contente de faire suivant suivant à l'installation.

Le comparer avec Wordpress est quand même abuser!

Et puis je pense que l'intégration complète d' eZComponents va propulser encore plus loin ce CMS (qui... défonce ;) )

++

- eZ publish et les CMS (#67693) par fonfec le 23 Mars 2009 à 08:06

Voici l'avis d'une non-technicienne (pour une fois !), mon rôle c'est d'accompagner le client dans l'utilisation des CMS (dont eZ).

Alors oui, certains clients choisissent eZ comme une marque, on va l'utiliser pour des petits sites qui peuvent être fait dans un autre CMS plus léger. Ca peut s'apparenter à du gaspillage de temps et donc d'argent.

Par contre dès qu'on répond à des demandes plus complexes (usine à site, sites avec entrées/sorties de données complexes etc..) eZ publish est le meilleur compromis. A conditions d'avoir des développeurs experts qui connaissent assez la gestion du cache.

Je connais aucun outil sans défaut, par contre je connais des développeurs qui connaissent mal les outils :-)

Comme on dit : PEBKAC

- C'est quoi la question (#67694) par Karlesnine le 23 Mars 2009 à 11:47

Je ne comprend pas bien ta question Damien
D'ailleurs, je suis curieux de savoir comment est géré la problématique multi-frontal
(médias uploadés dans le backoffice, éventuels caches, ...)

- Avec Drupal ! (#67696) par Damien le 23 Mars 2009 à 12:04

hum, il manquait un "avec Drupal" dans mon commentaire :-)

- ezxmlinstaller / data_import (#67697) par Nicolas Steinmetz le 23 Mars 2009 à 14:33

@jerôme : merci, je ne connaissais pas - je communique ça aux équipes de dev :-)

- Enfin de la polémique ! (#67698) par Gandbox le 23 Mars 2009 à 21:34

Je pense qu'on a faire à plusieurs phénomènes qui se superposent :

Le problème de management :
Imaginez vous à la direction d'un service informatique, avec des planning et des budgets à gérer. Vous avez empilé les mauvais choix (solution inadaptée au contexte, équipe peu expérimentée, projet instable...), et vous devez livrer votre site malgré tout ! Avec vos temps de réponses improbables que vous ne savez pas réellement expliquer (chacun rejette la faute sur son voisin, tout devient illisible) ! ARG ! 2 solutions :
- Échec d'architecture / stratégie / management...
- L'outil principal nous a trompé sur ses capacités... (c'est visiblement le choix de communication adopté)

La logique de Clan :
Le monde l'informatique raffole des histoires de clans, Windows vs Linux vs Mac, SAP vs Oracle, PHP vs J2E vs .NET... (moi je préfère l'Amiga à l'Atari). Une fois les clans formés, il ne reste plus qu'à compter les points, pour les argumentaires ils seront toujours contestables, "biaisés", etc.

Finalement eZPublish ou Drupal ou Wordpress ou l'assembleur ?
Au niveau performance, je vous conseille l'assembleur ! Ca déchire ! Finalement, chaque problématique trouve de bonnes et de mauvaises solutions, des outils adaptés ou inadaptés aux contextes... "parcequ'il n'existe pas de mauvais outils, mais seulement de mauvais ouvriers".

P.S : 2 défis à lancer :
- Développer ma cave avec Wordpress : http://www.gandbox.fr/ma-Cave
- Que Pierre Jean Duvivier publie son source eZ Publish :)

- Quelques points de reflexion en plus (#67701) par gaetano le 24 Mars 2009 à 22:48

"Tout ce qu'on peut faire avec eZpublish on peut le faire avec un autre CMS genre site vitrine (un wordpress suffit)."

Je ne suis pas tout à fait d'accord avec cette phrase. Avec php tout-seul on peut également faire tout site.

Et, si on a des bons codeurs, le site sera beaucoup plus rapide que eZ, Drupal, Symphony ou Wordpress.
Si on a des excellent codeurs, il sera aussi un site sur qui ne souffre pas de xss, sql-injection, xsrf et autre.
Enfin, si on a plein de temps, ce sera un site qui bénéficie de bonne doc sur sa structure et les apis internes.
Ah, j'oubliais, si on a de la chance, ce sera un site qui évolue bien car les codeurs qui l'ont fait seront toujours la. Si on ne l'a pas, on devra embaucher des nouveaux codeurs pour l'évolution qui ne seront même pas à hauteur de la tache de lire la doc et déferont tout en 2 semaines au cri de "c'est de la m...!"

En bref, les avantages d'utiliser un cms aussi vaste et 'lourd' qu'eZ ne sont pas tous à chercher dans le temps d'exécution d'une page ou dans le nombre de pages à la seconde.

Ce samedi, j'ai envoyé une requête sur la mailing list sdk interne, à 10h30 du soir. J'ai eu 6 réponses avant dimanche midi, ci inclus celle du chef du développement, celle du créateur original de l'outil et celle d'un guru renommé du langage php. Ça fait du bien de savoir qu'on travaille au sein d'une équipe aussi passionnée par ce qu'elle fait (bon ok, ça fait un peu triste aussi. Sortez plus, les gars!).

Je ne vais pas perdre de temps à comparer eZP avec WP, je pense qu'il ne soit pas nécessaire.

Par contre, quoi que je pense des très belles choses de Drupal et Symfony, je sais aussi que
- Drupal évolue vers une architecture à modèle d'objet flexible, comme eZP a fait depuis des années
- Symfony ne gérait même pas la création atomique des fichiers de cache jusqu'à une version très récente
Ceci semble indiquer que certains des problèmes de scalabilité de eZP ne sont pas reconnus comme problèmes pour des autres plateformes probablement parce qu'on ne celles ci n'ont même pas étées utilisées pour bâtir des architectures aussi complexes.

- Ez Publish ? Performant ? Ha ha ha... (#67752) par Florian Strzelecki le 10 Avril 2009 à 23:15

Houla, des grandes sites l'utilisent : oui ! Mais à quel prix ?

Par exemple, à Mondadori France Digital, qui l'utilise pour Topsante, Autojournal, Closer, et Pleinevie.

Sauf que... sauf que l'architecture ne tient pas la charge. Dans l'idée, Intel Xeon Quad, sur 5 serveurs + Squid : 3 frontaux + 1 backoffice + 1 base de données.

Déjà, on se demande pourquoi est-ce qu'il faut autant de serveur pour moins de 200.000 visiteurs par mois. Mais passons...

* La synchro du storage : ils pèsent tous entre 800 Mo et 2 Go. Pourquoi ? Va savoir... des centaines de répertoire dans tous les sens, des centaines de vignettes... et à synchroniser entre plusieurs frontaux, c'est juste une galère infame.
Sans parler du fait que c'est le template qui fait la génération des vignettes, et donc, ça devient encore plus dur de faire seulement une synchro minimale.

* Le cache : dans le genre de truc "aléatoire" en terme de fonctionnement, c'est assez balèze. Impossible de savoir exactement quand et comment il vide le cache, comment impacter réellement dessus. Et pire que tout, des fois, un --clear-all ne vide pas proprement le cache... il faut faire un bon vieux rm -rf à la main !

* La base de données : mais qui a pondu ce système pourrave ? Non mais, sérieux, sans déconner les mecs... c'est quoi l'idée ?

Outre le côté fastidieux de devoir refaire à chaque fois les modifs sur la version de dev / preprod / prod, il y a les risques de modifier une classe de contenu qui a déjà beaucoup d'instances...

* Les fichiers ini : mais pourquoi faut-il autant de fichier ??
Et le système de surcharge n'est pas clair : qui prend la main sur qui, dans quel sens, etc... ?

* Le langage de template : plus chiant et plus complexe tu meurs ! Je jette un coup d'oeil à Smarty : puissant, rapide, simple.
Celui d'EzPublish : relativement correct, lent, complexe.

Et je ne comprends toujours pas pourquoi il faut définir 50 fois les paramètres des tags de template personnalisé.

* Publication programmée : inexistante.
Oui, EzFlow c'est cool, on peut décider quand le contenu remonte. Mais concrètement, il n'existe aucun moyen de base pour la publication différée sur l'ensemble du site.
Et ça, pour un CMS, ça craint un max quand même.

~~~

Et pour faire une petite comparaison avec des Framework comme Symphony en PHP et Django en Python, EzPublish est clairement une mauvaise solution technique et marketing : ni DRY ni KISS.

EzPublish a, pour lui, Ez.no et ses commerciaux, d'une redoutable efficacité.

DRY : Don't Repeat Yourself
KISS : Keep It Simple Stupid

- hahaha :) (#67753) par Damien le 11 Avril 2009 à 00:48

@Florian : tu serais pas du genre "je comprend pas comment ça marche, donc c'est nul" par hasard ?
Sinon pour répondre aux parties intéressantes de ton commentaire (pour le reste en cherchant un peu, tu dois être capable de comprendre...) :

La base de données : on appelle ça le modèle EAV, comme tout choix, ça a des avantages et des inconvénients. Le gros avantage, c'est la souplesse.

Template : oui le moteur de template d'eZ Publish est pénible. en revanche, c'est marrant que tu cites Smarty comme référence, étant donné que celui d'eZ Publish dérive de Smarty... :) Et pour les opérateurs, effectivement c'est un peu (beaucoup!) pénible mais on peut éviter de se répèter avec quelques trucs simples (c'est du PHP quoi !)

Publication programmée : je crois que tu as mal cherché entre les mécanismes DANS eZ Publish (indice : content.ini) et les nombreuses extensions qui fournissent des alternatives on doit pouvoir trouver son bonheur (sans avoir une ligne de code à écrire...).

Sinon eZ Publish ne se place pas tout à fait en face de Django ou Symfony, bref comparons ce qui est comparable. Sinon pour le DRY, c'est faux puisque justement eZ Publish apporte les briques CMS qui peut manquer sur certains projets si tu pars avec un framework et que tu vas invariablement faire et refaire. Pour le KISS, effectivement il faut reconnaître que ce n'est pas toujours simple, mais le vie n'est pas forcément rose avec d'autres solutions non plus :-)

Enfin pour les exemples de site, on trouveras toujours des sites mal faits dans toute techno, il ne faut pas confondre la solution technique et sa mise en oeuvre... Et je pense que sur les chiffres que tu donnes, il doit y avoir une grossière erreur, 200 000 visiteurs par mois c'est pas très éloigné de ce que ce site fait (~140000) sur ... 1 Dedibox ancienne génération pas vraiment surchargée hébergeant plusieurs autres sites... :)

- Owi... (#67754) par Florian Strzelecki le 11 Avril 2009 à 12:43

@Damien : non, loin de là. Au contraire, je serais du genre à comprendre...

Pour les 200.000 visites / mois, c'est pour chaque site. Donc on se retrouve avec environ 6 à 800.000 visites / mois sur cette architecture.

* La base de donnée : souple ? Faire un fetch sur plusieurs attributs, incluant des "AND" et des "OR" n'est pas simple du tout, voir carrément infaisable dans certain cas.

Ensuite : à quel prix ? J'ai déjà eu à vérifier des requêtes SQL généré par EzPublish : plus d'une trentaine de AND, et environ autant d'opération & (bit à bit).

"Le gros avantage, c'est la souplesse." Et le gros inconvénient, c'est la performance. Là encore on fait mieux pour le côté "scalable".

Enfin, pour une version 4, on s'attend à mieux niveau correctif de bug et gestion du modèle de données.

* "Etant donné que celui d'eZ Publish dérive de Smarty" : ce qui est faux. Ayant suivi une formation avec un formateur d'eZ Système, je lui ai posé la question.
En fait, ils ont été fait grosso modo à la même époque - je ne fais que le cité, m'aurait-il menti ? - et la différence, c'est que Smarty a évolué vers un système à la fois performant et souple.

Celui d'Ez Publish reste potable - il fait quand même le job - mais la compilation du template est un véritable gouffre de performance, comparé, là encore, à Smarty.

* "les nombreuses extensions qui fournissent des alternatives" : je trouve ça réellement dommage qu'il faille trouver l'alternative au système EzPublish de base.
J'attends d'un CMS un minimum de fonctionnalités. Lorsque le directeur Europe d'Ez.no vient voir mon patron et lui explique que ça gère très bien le workflow et la publication programmée, je ne sais pas où il a vu ça.

Et oui nous avons cherché et finalement développé une petite extension en plus, pour palier à ce problème (avec un Content Edit Handler entre autre, dont je me suis occupé - quand je dis que je comprends quand même pas mal de truc). Mais je trouve ça toujours aussi hallucinant : là encore, un produit censé être "professionnel" en version 4, 10 ans d'existences d'Ez Système... wahou.

* "Sinon pour le DRY, c'est faux" : euh... bah non hein.
J'ai pris l'exemple des opérateurs de template, mais il y a un problème sous-jacent à tout ça : ce n'est pas vraiment du php5 tout ça.

Grosso modo, la plus part des modules de base (je pense aux Users par exemple), est très "procédural". Alors oui il y a des classes php, mais il faut presque tout ré-écrire soit-même à chaque fois qu'on veut ajouter de la fonctionnalité.

* "apporte les briques CMS qui peut manquer sur certains projets si tu pars avec un framework" : je te retourne ta première remarque : tu ne serais pas du genre à ne pas connaître les-dit framework dont je parle, et à faire ce genre de supposition ?

Je ne me connais pas encore très bien en Symphony - je serais plutôt Django - mais j'ai un collègue expert. Et, concrètement, alors qu'il est complexe de reprendre une extension d'un site Ez vers un autre, c'est un véritable jeu d'enfant en Symphony. Dans Django c'est même un quasi pre-requis des applications.

Symphony, comme Django, préfère décrire les modèles dans des fichiers de code, et tout deux génèrent une interface d'admin.

Ez Publish demande de décrire les modèles dans la base de données, via une interface d'admin manquant cruellement d'ergonomie.

Ensuite, non en effet, on ne peut pas mettre complètement en face Django/Symphony et Ez.

Django est en python, les deux autres en php.
Symphony et EZ sont supportés par des entreprises, pas Django.
Ez se fait vieux, Symphony est récent, et la version 1.0 de Django date de Septembre 2008.

Bref, EzPublish aura peut-être fait son temps, et je ne lui reproche pas d'avoir proposer une solution professionnelle à des entreprises.

Je lui reproche, aujourd'hui, d'être un calvaire pour les développeurs, et de ne pas avoir su s'adapter aux nouvelles technologies, aux nouveaux concepts.

- Framework / CMS / ... (#67756) par Damien le 11 Avril 2009 à 13:53

"Pour les 200.000 visites / mois, c'est pour chaque site. Donc on se retrouve avec environ 6 à 800.000 visites / mois sur cette architecture."
et personne ne se dit que ça viendrait peut être de la qualité de réalisation ? Parce que franchement, ce ne sont pas chiffres énormes. Mais évidemment, il est plus facile de remettre en cause la solution que son propre travail :-)

Pour la base de données effectivement, c'est le point faible mais justement une bonne réalisation permet d'éviter bien des problèmes. Et puis au fil des versions des optimisations arrivent qui en font un outil de plus en plus efficace.

Pour la publication différée, il y a un système de ce type DANS eZ Publish (je le répète) ! Les extensions fournissent d'autres manières de faire et te permettent d'écrire la tiennent, franchement que faut il de plus ? fournir toutes les fonctionnalités possibles et imaginables ?

Je ne fais pas de suppositions sur les frameworks, deux appellations différentes, deux produits différents avec des points communs, des avantages, des inconvénients... eZ Publish est un CMS, il se positionne plus haut dans la pile qu'un framework pur "à la symfony" même si ce que je trouve justement intéressant dans eZ Publish c'est son côté un peu framework qui lui donne plus de souplesse que le CMS moyen (mais moins qu'un framework pur, c'est évident). Au passage ça n'a rien à voir avec le langage sous-jacent.

- Remise en cause ? (#67757) par Florian Strzelecki le 11 Avril 2009 à 15:50

Mais tout à fait ! La remise en cause du code a été faite. D'ailleurs, nous avons passé beaucoup de temps à comparer le travail fourni sur Closer par un prestataire, et Topsante, fait en interne. Et le résultat est net : Topsante tient mieux la charge que Closer.

Ensuite, il y a la question de la volumétrie : entre 8 à 10.000 contenus éditoriaux (articles et dossiers compilation) pour Topsante, et environ 10 articles par jour dans Closer (soit une base de contenu d'environ 6 à 8000 articles)
Vient ensuite la communauté, qui représente entre 30.000 user pour chaque site.

Au début, pour Topsante, nous n'avons eu aucun problème majeur de performance. Après tout, voir 600 requêtes SQL pour générer la home la première fois nous semblait juste ahurissant, mais les serveurs tenaient bon.
Et puis Closer. Environ 1200 requêtes SQL pour la home.
Sans doute il y a-t-il un problème avec le nombre de contenus à remonter sur la home. Mais bon, si on doit se limiter à des homes basiques façon Blog... à quoi sert donc Ez ?

Au final, avec le nombre de contenus saisi, et les données des Users, chaque base de données fait environ 5 à 600 Mo. Comment l'expliquer ?

La remise en question du développement est nécessaire, bien entendu. D'ailleurs, c'est tout ce qui est demandé à EzPublish : que ses développeurs se remettent un peu en question.

Là où on me parle des avantages de la souplesse, je pointe les inconvénient des performances.
Tu compares ton exemple aux miens, en disant qu'ils sont semblables. Admettons. Je veux bien voir la complexité du site en question.

Mais à côté de ça, je vois que des sites comme le Guide Télé, qui fait plus de page vue que Closer et Topsanté réuni, fait en ZF+Smarty, ne demande qu'un seul serveur, qui ne pose aucun soucis de charge... je me dis qu'il y a quand même un problème dans les outils employés.

- Petit oubli (#67758) par Florian Strzelecki le 11 Avril 2009 à 15:55

> "Au passage ça n'a rien à voir avec le langage sous-jacent."

Non en effet. D'ailleurs, j'ai préféré apporté un exemple PHP et un Python, et je n'ai pas insisté sur Django.

Mais en restant seulement sur PHP, on peut clairement voir que Symphony utilise bien mieux le modèle objet qu'EzPublish.

Et c'est de ça dont je parle quand je dis "nouvelles technologies". Quoi que... php 5 n'est plus si "nouveau" que ça.

- blagueur (#67759) par Damien le 11 Avril 2009 à 17:20

ne me fait pas dire ce que je n'ai pas écrit. J'ai écrit que les audiences que tu cites ne pas incroyables et qu'elles sont comparables à un site que je connais parfaitement (en fait à plein d'autres). Mais la comparaison s'arrête là, les sites sont évidemment très différents.

"Et puis Closer. Environ 1200 requêtes SQL pour la home.
Sans doute il y a-t-il un problème avec le nombre de contenus à remonter sur la home."
C'est une blague là ? Je comprend pas comment les seules raisons que tu envisages au sujet d'un truc pareil soit le fonctionnel ou l'outil mais pas la manière dont il est mis en œuvre.

"La remise en question du développement est nécessaire, bien entendu. D'ailleurs, c'est tout ce qui est demandé à EzPublish : que ses développeurs se remettent un peu en question."
et ceux qui ont fait le site à partir d'eZ Publish, ils font des choses parfaites c'est ça ? Je sais, il n'est pas facile de se remettre en cause.

À propos de Guide Télé : quelque chose me dit que c'est un site bien plus simple. Pas de compte utilisateur, pas de mise à jour en permanence, bref c'est presque statique. Cela dit ça marche quand même pas super bien : http://www.guidetele.com/programm...sport/canalsat/apres-midi/2009-04-12 :p

Bref, je suis pas là pour faire un audit de vos problèmes de perf !

- Ah, le Guide Télé :') (#67760) par Florian Strzelecki le 11 Avril 2009 à 18:32

Il y a pas mal de problème d'import pour le Guide Télé. Et c'est pas si simple qu'on le croit - sinon ça fait belle lurette qu'il fonctionnerait comme il faut. Perso j'ai jamais bossé dessus.

Bref, pour les 1200 requêtes : en fait, on a optimisé comme on a pu. C'est géré avec EzFlow, et il y a un cache-block pour chaque bloc, mis à 1 heure.

Donc, pour la remonté de contenu... je vois mal quoi faire à part un "foreach $block.valid_nodes as $content"...
Et pour afficher le titre, un "$content.name|wash" et un attribute view gui sur le "$content.data_map.photo".

Je vois pas comment faire pour améliorer ça : plus de 90% du contenu remonte comme ça. Il y en a une petite partie (le forum) qui est géré via un WebService, les tags pub, et, à l'occasion, des blocs codés en dur (pour des besoins spécifiques market le plus souvent).

Après une mise en cache, la home demande seulement entre 4 et 7 requêtes SQL. Parfait ! Sauf que... le contenu doit être mis à jour environ tous les 15min.

L'orientation du site Closer est la news chaude et rapide, et 15min c'est déjà limite pour eux. Sauf que vider les caches - et nous avons fait appel à un expert certifié Ez Publish pour nous aider là dessus - toutes les 15 min, ça provoque la surcharge.

La seule solution, ce sont des mises à jour moins fréquentes...

Alors la souplesse ?
Quant à la remise en question, je note que j'apporte un maximum d'exemple et d'arguement, et qu'en réponse, j'ai droit à un "remet en cause ton code".

Hm hm... oui, bien sûr. Et ta remise en question sur un outil qui a clairement des défaillances graves ?

Poutre, paille, oeil etc...

- ma remise en question ? (#67761) par Damien le 11 Avril 2009 à 19:57

"Il y a pas mal de problème d'import pour le Guide Télé. Et c'est pas si simple qu'on le croit - sinon ça fait belle lurette qu'il fonctionnerait comme il faut."
je me doute bien mais en terme de front office, c'est un cas idéal pour les performances.

"Bref, pour les 1200 requêtes : en fait, on a optimisé comme on a pu. C'est géré avec EzFlow, et il y a un cache-block pour chaque bloc, mis à 1 heure."
et pourquoi 1 heure ? pourquoi pas juste quand c'est nécessaire? C'est exactement le genre de règle arbitraire qui a parfois des effets insoupçonnés (et ça n'a rien de spécifique à eZ Publish d'ailleurs).

"Après une mise en cache, la home demande seulement entre 4 et 7 requêtes SQL. Parfait ! Sauf que... le contenu doit être mis à jour environ tous les 15min."
la page change pas entièrement toutes les 15 minutes et c'est justement là que le bon usage des cache-block fait toute la différence.

"Quant à la remise en question, je note que j'apporte un maximum d'exemple et d'arguement, et qu'en réponse, j'ai droit à un "remet en cause ton code"."
Je connais eZ Publish, je connais en gros la problématique sur un site comme Closer (celle de n'importe quel site d'actu en fait), tu m'as donné un vision grossière de l'audience ainsi que de l'architecture; la seule chose sur laquelle je n'ai aucune connaissance c'est justement le code. L'expérience montre qu'il est rarement aussi bon qu'on croit. Si à ça tu rajoutes des erreurs au niveau système tu as les causes de 95% des problèmes que j'ai pu rencontrer.

"Hm hm... oui, bien sûr. Et ta remise en question sur un outil qui a clairement des défaillances graves ?"
je vois pas en quoi *tes* problèmes devraient me faire remettre en question quoi que ce soit ?

- Passons alors... (#67762) par Florian Strzelecki le 12 Avril 2009 à 01:32

... puisque moi je dois remettre en cause mon code, et que, pour toi, les problèmes ont tous des solutions.

Sans doute. Sûrement même. Voir, carrément. Avec un CDN comme Akamaï (solution utilisée par Lagardère-Hachette). Avec des reverses proxy comme Squid ou Varnish. Avec plusieurs serveurs MySQL.

Sans doute aussi, avec une équipe de développeur qui doivent être formés, encadré, et avoir une longue expérience. Et une équipe d'au moins 10 personnes, sinon ça ne compte pas. Et avec au moins un expert d'eZSystem ou un ingénieur qui y a passé les 5 derniers années de sa vie professionnelle - et sans doute personnelle.

Sans doute aussi, avec des budgets de développement et de maintenance qui crèvent le plafond. Bah oui, beaucoup de développeur, et comme il leur faut entre 5 et 15 secondes pour générer chaque page, vider un cache, changer un fichier de settings, revider le cache - des fois ça marche mal - re-attendre 10 secondes, et voir qu'il faut tout recommencer... tout ça, ça prend un temps fou.

Bref, je remets en cause le rapport coût / produits, qui, pour moi, est clairement en défaveur d'eZP, et en faveur d'autres solutions, aujourd'hui beaucoup plus performante, et qui évoluent plus vite qu'eZP.

Pour ne citer qu'eux, Drupal, Symphony, Django.

- Une bonne fois pour toute (#67763) par Damien le 12 Avril 2009 à 10:50

une bonne fois pour toute, *JE* n'ai rien à voir avec *TES* problèmes. Et oui la plupart des problèmes ont des solutions. Après, libre à toi de penser ce que tu veux, mais encore une fois je ne vois pas en quoi *TES* problèmes sur lesquels je n'ai qu'une vision grossière devraient *ME* faire revoir quoi que ce soit.

-- FIN de la discussion --

- perfs (#67897) par Charly le 10 Août 2009 à 09:17

Je veux pas relancer de debat ou quoi... Mais c'etait juste pour preciser qu'apres migration d'un apache1.3 / php4 / eZpublish 3.10 vers un apache2 / php5 / eZpublish 4.1 en effet, mes temps de reponse sont deux fois plus courts.

- mon avis perso (#67927) par helloworld le 02 Septembre 2009 à 20:21

bref, tous autant que vous etes pour moi deja vous etes tous des noobs a vous battre en comparaisons diverses et variées sur des langages interprétés qui par définition sont juste de la merde pour sous golios de l'informatique. voila, vous savez ce que je pense donc du php, (j'ai une mauvaise opinion de java, vb.net et cie et csharp, modérée par leur compilateur a la volée).... toutefois, aujourd'hui y'a que du boulot de noob et faut bien manger. toujours est il qu'avec un peu d'efforts - mais encore faudrait il que les entreprises possedassent un minimum de cerveaux dans leurs rangs - il est tout a fait possible de faire du web vraiment compilé sans meme passer par le cgi ou fast cgi. je fini, pour moi ez publish, c'est pas du bon. ne serait ce qu'a la fin de l'install, apres moult messages obscures laissant entendre que j'avais pas de moteur de base de données sur mon pc, n'a reussi a afficher peniblement qu'une page a moitié vide apres 4 ou 5 time out. oui, ca rame, c'est le moins qu'on puisse dire. en plus, a l'instar de symfony (que je n'apprecie que politiquement parlant devant les decideurs toujours plus intelligents) il faut taper dans les fichier .ini de php ou apache pour avoir une config correcte. cela exclu donc quasiment la possibilité d'installer le dinosaure sur des sites providers tels que free. bref, mais la faute a qui ou quoi? selon moi, evidemment a des programmeurs qui s'improvisent programmeurs objet du jour au lendemain et surtout a php : fondamentalement, un langage interprété, c'est fait pour ramer (lol j'ai lu un mec qui voulait pas "stresser" sa base de données mdr grrr) mais si en plus il est orienté objet avec héritage, polymorphisme actif, et tout les nouveaux concepts qui font qu'on desintegre la mémoire en chargeant des tables entieres dans des classes object avec des getters metier au lieu de balancer ca sur le web directement, bin faut pas s'etonner du resultat : ca pédale dans la semoule. donc, moi, je suis pas content mais j'ai le choix alors je supporte. mais un jour, un jour... oui un jour je me vengerais d'avoir du bouffer de l'interprété au mépris de tous les bons sens !!! ;)

- aion (#68024) par aion gold le 04 Novembre 2009 à 10:53

Je t'invite aussi à lire la documentation dans le fichier config.php-RECOMMENDED [2], particulièrement la constante EZP_INI_FILEMTIME_CHECK qui permet d'économiser pas mal d'i/o aussi au niveau des fichiers de settings.

» Trackback

- Some due modifications to the eZ Cluster sur Some due modifications to the eZ Cluster

Some due modifications to the eZ Cluster

Les trackacks sont désactivés