Via High Scalability, j'ai découvert cette présentation intitulée Real World Web: Performance & Scalability donnée lors de la MySQL conference 2008 par Ask Bjørn Hansen. Cette longue présentation (189 pages !) est une excellente compilation de la plupart des conseils que l'on peut trouver un peu partout pour améliorer les performances et l'extensibilité (au niveau de l'architecture) d'une application web par exemple à base de MySQL et du langage de votre choix (PHP, Perl, Ruby, ...)
On peut y trouver également quelques petites phrases assez amusantes du type (traduction libre) :
N'hésitez pas à dé-normaliser les données; [...] appelez cela des summary tables, votre DBA n'y prêtera même pas attention.
où encore une jolie manière d'expliquer les concepts de MVC et d'API
Model : parle le SQL
View : parle le HTML
Controller : parle le HTTP
API : fait des trucs
Bref, ce document mérite de s'y attarder quelques minutes :
Sur un tout autre sujet, Artisan Numérique publie un benchmark de PostgreSQL entre les versions 8.2 et 8.3 et ensuite avec quelques optimisations. Je suis loin d'être un spécialiste et un grand utilisateur de PostgreSQL mais c'est toujours intéressant surtout avec le flou régnant autour de MySQL depuis le rachat de Sun par Oracle.
Enfin, ça n'aura échappé à personne s'intéressant un peu à PHP; après une longue gestation, PHP 5.3 est sorti. Cette version apporte son lot de nouveautés au niveau du langage plus ou moins intéressantes (beurk le goto et le séparateur de namespace) mais aussi des améliorations de performances. Dans le forum sur eZ.no, Björn Dieding rapporte un gain de 90% sur Windows avec eZ Publish + PHP 5.3 par rapport au même site tournant avec PHP 5.2 ! Łukasz Serwatka a réalisé le même benchmark sous Linux observant un gain de l'ordre de 20% !
Le résultat est plutôt spectaculaire. La simple mise à jour en 4.1 donne un gain de presque 30% dans la distribution d'une page en cache ! Avec la configuration ci-dessus dans le fichier config.php le gain est même de 50% ! Pendant les phases de tests, j'ai également constaté que la charge de la machine est bien plus faible. Comme d'habitude ces chiffres sont à prendre avec des pincettes, ils représentent le gain sur un site bien optimisé (enfin j'espère) sur un serveur bas de gamme. Un test sur un serveur plus haut de gamme serait vraiment intéressant.
Première chose, les informations fournies dans ces billets sont assez confuses voire inexactes (voir le paragraphe intitulé eZpublish ré-invente la compilation en PHP par exemple), je pense qu'il s'agit de la vision non technique de problèmes techniques, en fait ce qui ressort avant tout, c'est la frustration de l'auteur. Ensuite, la comparaison brute des chiffres Drupal / eZ Publish est complètement biaisée. Comparer des installations eZ Publish 3.8 utilisant PHP4 avec des installations de Drupal utilisant probablement PHP5, ce n'est pas très sérieux ! eZ Publish 4.0 (avec PHP5) est 2 fois plus rapide qu'eZ Publish 3.10, alors par rapport à eZ Publish 3.8... Je connais mal Drupal, donc je ne parlerai donc que d'eZ Publish.
Bref, en essayant de démêler tout ça, l'auteur dénonce finalement deux problèmes :
Une architecture technique complexe en raison des mauvaises performances supposées du CMS
Des difficultés de développement et d'évolution du/des sites.
Architecture, performances...
Avec une estimation à la louche, 500 000 pages vues par jour correspond à moins de 30 pages / secondes en pointe, un nombre certes respectable mais qui ne donne jamais que 8 pages / secondes sur chacun des 4 frontaux qui étaient d'après les articles des bi-Xeon quadcore ! Par expérience, la plupart du temps la cause de ce genre de problèmes est souvent une ou des énormités de configuration au niveau système ou au niveau applicatif. D'ailleurs dans ce cas, je me pose la question de la pertinence d'héberger plusieurs sites sur la même grosse plateforme plutôt que de séparer chaque site sur sa propre plateforme plus légère ?
Mais tout n'est pas 100% blanc ou 100% noir ; la version 3.8 d'eZ Publish était la première à implémenter le mode cluster tel qu'on le connait actuellement (tout ce qui est relatif aux contenus est dans une base de données) et il est clair que ce mode souffrait de défauts de jeunesse importants. Ce mode a été grandement amélioré au fil des versions, en version 3.10 et 4.0, il me semble que ça fonctionne bien et la version 4.1 apporte encore des améliorations importantes avec notamment le Stale cache, Charles-Christian Croix en parle également. Il y a aussi un excellent fil de discussion sur le mode cluster d'eZ Publish et comme suggéré par Bertrand dans ce fil, un article référence sur les architectures de ce type serait le bienvenu ! Donc pour revenir à la question initiale, au niveau des performances, il est clair que la version actuelle d'eZ Publish fonctionne mieux (le contraire serait malheureux).
Le développement
Le second point soulevé par l'auteur est la difficulté de développement et de maintenance (et la maintenance je connais !). Là encore tout n'est pas blanc ou noir. eZ Publish est un outil assez complexe, c'est un fait mais ce n'est pas insurmontable ! Il semble qu'il y ait eu un mélange entre mauvaises pratiques et réels problèmes techniques. Exemple, le fait de mettre des identifiants dans les fichiers de configuration est une pratique à utiliser avec parcimonie. La sur-utilisation de ce genre de mécanisme est clairement une très mauvaise pratique et souvent révélatrice d'une mauvaise conception des contenus. En revanche, le problème de mise à jour d'une classe avec beaucoup d'instances est clairement un vrai problème, ce point a été amélioré mais il existe encore mais il est néanmoins contournable. Et puis les problèmes de performances exposés juste au dessus ne sont probablement pas étranger à d'autres mauvaises pratiques ou d'autres manques dans le développement ou la conception.
Et pour finir quand je lis que d'excellents développeurs PHP ont du mal à utiliser le langage de template d'eZ Publish, on frise le ridicule.
Conclusion ?
Il y a probablement une partie de réels problèmes dans les points remontés dans les articles de Pierre Jean Duvivier (eZ Publish n'est pas parfait) mais il est toujours plus facile de démonter une solution dans son ensemble que de se remettre en cause... Le fait est qu'eZ Publish est utilisé sur une large palette de sites à plus ou moins fort trafic et les chiffres indiqués ne sont pas non plus exceptionnels !
Et pour revenir au commentaire initial, oui les problèmes imputables à eZ Publish sont réglés petit à petit mais il ne faut pas oublier que la qualité de la mise en oeuvre de l'outil est largement aussi importante que l'outil lui-même !
