Comme on parle pas mal des performances de eZ publish dernièrement (Blog de tigrou, blog de Karlesnine), et que c’est un sujet qui me tient à coeur, il est temps de poster quelques chiffres concret.
J’ai testé quelque chose d’assez simple, pas forcément super réaliste, mais à mon sens tout de même significatif: les performances brutes en termes de requêtes / seconde sur une seule et même page en cache, d’une part en mode standard (eZFS), d’autre pat en mode cluster DB (eZDB). Le test est effectué via jmeter, les pages servies étant enregistré sous forme de CSV, chargé et retraité ensuite dans OpenOffice pour générer un joli petit graphe. Pfiou. Un peu complexe, mais une fois en route, on obtient de beaux graphes, assez lisibles, et des données utiles.
Performances eZDBFileHandler
Performances eZFSFileHandler
Analyse rapide
Je ne vais pas m’étendre 2 heures sur ça, mais une petite conclusion rapide: en consultation pure, eZFS sert en moyenne 10% de requêtes supplémentaires comparé à eZDB. Cela permet d’ores et déjà de voir que dans ces conditions, l’utilisation de la base de données comme “passerelle” de cache a un impact relativement faible.
On remarquera aussi qu’on est en moyenne à60-80 requêtes / seconde en eZDB, et70-90 requêtes / seconde en eZFS. Dans l’ensemble, des chiffres assez élevés (250 à 300 000 pages vues / heure). Bien entendu, un cluster avec un seul serveur ne présente pas non plus beaucoup d’intêret.
J’essaierai dans une prochaine étape de fournir ces mêmes données avec des publications, mais j’ai encore quelques difficultés à programmer de manière mesurable des opérations de publication pendant le bench.
8 responses so far ↓
1 Sylvain_G // mar 31, 2009 at 23:29
Et bien c’est pas mal du tout tous ca, cependant,
1. je ne pense pas que 10% de perte soit réellement négligeable.
2. pour avoir un comparatif pertinant il faudrai comparer le mode cluster Ez et une installation ezFS + NFS + DRDB
parce qu’après tout, tous cela est pour faire de la distribution ou de la haute disponibilité.
2 Karles // avr 1, 2009 at 10:19
ezFS + NFS + DRDB ??
C’est quoi le rôle de DRDB dans cette architecture ?
3 Karles // avr 1, 2009 at 10:20
Y’ pas de trackback sur ton blog ? Dommage :)
4 Bertrand // avr 1, 2009 at 11:33
Il devrait y avoir du trackback, Karles… faut vraiment que je remplace ce Wordpress par du eZ. Cependant, il suffit d’ajouter /trackback à la fin de l’URL (http://blog.ankh-morpork.net/2009/03/30/ez-publish-41-numbers-ezdb-vs-ezfs/trackback) et ça devrait rouler.
Sylvain: sur les 10% je comprends parfaitement. Après, le fait est que le cluster DB a un impact sur les perfs, on ne pourra jamais le rendre aussi rapide qu’un mode pur FS. Cependant il faut quand même se rappeler que le but est de clusteriser le tout, donc en soi on ajoute une machine et on est à +80% par rapport à un serveur en eZFS.
Dès que possible je ferai aussi du test avec 2 machines dans le cluster, ça demande juste un peu de travail d’archi…
5 Karlesnine.com // avr 1, 2009 at 13:51
Bench entre eZDB vs eZFS de eZ publish 4.1…
Bertrand Dunogier publie un petit benchmark entre eZDBFileHandler et eZFSFileHandler de eZ publish 4.1. Le sujet est très intéressant, d’abord car l’aspect purement AdminSys des site en eZ est sous documenté sur le net. En suite car eZ system à s…
6 Sylvain_G // avr 1, 2009 at 23:38
@Bertand oui c’est sur que le cluster à un impact et comme tu le fait remarquer l’idée est bien de pouvoir facilement ajouter un frontal web pour avoir une distribution horizontale de ton architecture
+80% en ezDB, mais combien avec un ezFS + partage NFS
ps: ca serai sympa de refondre ce site sous Ez et d’y mettre des articles sur les méthodes et technique que tu aura mis en oeuvre!
@Karles DRDB c’est pour une archi ou tu souhaite avoir de la haute disponibilité sur ton montage NFS, No Single Point of Failure
Je me demande s’il est possible de glisser un memcached entre le ezFS et le ezDB pour le cache template et vue?
7 Bertrand // avr 2, 2009 at 10:14
@Sylvain: un des soucis sur les archis basées sur des systèmes de fichiers distribués, c’est le manque de visibilité sur le serveur NFS (ou autre). On a eu d’assez mauvaises expériences avec tout ça, et on sait que le résultat est extrêmement dépendant des technos. L’autre souci est que pour le moment nous n’avons pas l’archi en france pour tester les perfs de ces archis, mais nous y travaillons. Dans tous les cas, j’ai une assez grande confiance en l’approche cluster BDD, même si celle-ci demande des évolutions. Et on a des idées :)
Concernant la refonte en eZ, c’est prévu…
Enfin sur memcache, j’ai justement testé ça en début de semaine, et je n’ai pour le moment pas noté d’amélioration flagrante… je pense que le query cache MySQL limite déjà très nettement l’impact de memcache dans l’histoire. Ce que j’ai fait est d’ailleurs dispo ici: http://projects.ez.no/memcachedcluster (approche très très expérimentale, sur base de triggers MySQL mettant memcache à jour).
8 Sylvain_G // avr 3, 2009 at 20:19
pour le cluster BDD je suis content d’entendre que vous avez encore des idées d’améliorations, parce que moi je trouve qd même enbêtant de sauvegarder des gros binaires en Base, surtout si il y a des vidéos etc. En tous cas le StaleCache est clairement un grand pas dans la bonne direction.
Pour un cluster fichier, je regarde aussi la solution retenu par Digg: http://www.danga.com/mogilefs/ un espèce de cluster WebDav pour un autre projet.
Pour memcached, je pensais plus à l’utiliser pour le ViewCache et les Cache-Blocks
Leave a Comment