Voici.fr et Gala.Fr utilisant eZ Publish ont survécu à la mort de Michael Jackson

La mort de Michael Jackson submerge Internet

La mort de Michael Jackson à enflammé le web mondial au point que certains services et sites ont eu du mal à soutenir l’audience comme le rapporte TF1, Le Parisien ou encore Le monde Informatique.

Même pas mal !

A force d’un travail constant de recherche de performance tant par la remonté d’information, de log et de question aux développeurs que par l’étude de configuration fine des reverse proxy squid, des apaches et des mysql nous avons encaissé la vague médiatique de la mort de Michael Jackson

Les records d’audience avec eZ publish

Je vous parlais récemment du score fait par un de nos sites en eZ 4. Or ce site est hébergé sur une plate-forme d’hébergement mutualisée de notre conception (ou presque). Ce jour de score la plate-forme entière à également battue son record : lundi 22/06/2009 1 397 524 pages vues

Depuis avec la mort de Michael Jackson nous avons eu deux nouveaux record d’audience sur la même plate-forme. le vendredi 26/06/2009 avec 1 623 589 de pages vue et le lundi 29/06/2009 avec 1 829 122 de pages vues.

Attention, je parle bien de pages vue pour l’ensemble de la plate-forme qui accueil en toute et pour tout 3 sites eZ 3.x, 3 sites eZ 4.x et une poignet de blog WP. Certains sites font 2K page vues en 24h d’autre 600K. Seul deux de ces sites on connue le pic d’audience généré par la mort de Michael Jackson.

Tenir cette charge avec eZ

Même pas mal. Cette audience est événementielle et s’applique sur un nombre de page / article réduit ce qui ne consomme pas des ressources sur l’intégralité de la plate-forme. Les pages en question n’ont pas à être fréquemment calculé par eZ car elle ne change pas beaucoup. De ce fait les frontaux et base de donnée sont sollicité mais pas de façon proportionnel à la monté de l’audience. Par contre les reverse proxy sont eux très fortement sollicité pour distribué massivement les quelques pages demandées (60 Mb/s en sortie). La configuration des trois serveurs squid en mode reverse proxy à été essentiel. L’infrastructure réseau doit être capable d’accepter un grand nombre de connexion tcp (je pense au routeur et répartiteur de charge). Dans un cas la bande passante est passé de 68Mb/s à 170Mb/s en cinq petites minutes avec l’effet slash dot de google actu et yahoo actu !

170MbsDeBP.jpg

PageVuePlateForme.jpg

SlashDotAvecYahooActu.jpg

6 réflexions sur “ Voici.fr et Gala.Fr utilisant eZ Publish ont survécu à la mort de Michael Jackson ”

  1. Chapeau bas, c’est beau de prouver la validité de son archi. Avec varnish tu n’aurais même pas regardé ton reverse proxy.

    je remballe mon troll et je sors ? ok 🙂

  2. Merci merci Bertrand 🙂

    Bon alors trollons gras sur varnish vs squid, si si même pas peur.

    Varnish à tout de la marié la plus sexy du monde pour un responsable d’application eZ Pubish. Le dialogue reverse proxy <-> eZ est optimum. L’application pouvant elle même demander qu’un élément soit vider du cache varnish car ellle vient justement de le modifier. J’avoue que rien que cela c’est tip top. Si on ajoute le support de ESI c’est carrément le nirvana pour développeur.

    Bon seulement je suis pas développeur mais Admin sys. Et je suis pas en charge d’une application mais d’une plate-forme mutualisée d’hébergement. Or vus sous cette angle quelque contrainte ce pose.

    Varnish et eZ 3.10 peuvent ils ce comprendre et l’application peut elle même demander qu’un élément soit vider du cache varnish car ellle vient justement de le modifier ? Varnish ne connaît pas l’ICP, rien que cela pour un Admin sys est rédhibitoire. Faute de mettre cela en pratique varnish impose un surcoût (financier / temps) pour résoudre les contraintes de tolérance au panne, de haute disponibilité et de répartition de charge, sans parler de la surcharge sur les frontaux.

    Alors le pool de reverse proxy squid que nous avons mit en place n’offre peut être pas les possibilités les plus sexy pour les mono-maniac de eZ publish mais il offre un service de type nuage de cache ou CDN qui couvre les besoins pour plusieurs type d’application , eZ 4.x, eZ 3.10, WordPress, pure LAMP maison et quelque truc avec symphony. En outre chaque squid échangeant son cache avec ces congénères il n’y à pas d’interrogation abusive des frontaux. Le tout offre des garanties de tolérance au panne, de haute disponibilité et de répartition de charge avec un LVS en amont à la configuration des plus simple.

    Voila voila

    Quand je vois ce que dit Poul-Henning Kamp sur ICP je crois que je vais pas changer d’avis bien vite. Sans vouloir atteindre le point Godwin à la vitesse de l’éclair je note une certaine intolérance de ce garçon pour ICP.

  3. @Charles-Christian Croix : ah ça ce sont des arguments intéressants (plus que les stats de voici.fr AMHA) Sinon Squid 3.0 supporte aussi les ESI, j’ai pas testé cela dit.

  4. @Damien, toi je te vois venir de loin avec l’ESI, tu salive d’avance sur les possibilités offerte, tu rêve de faire un petit test a l’échelle 1:1 juste histoire de voir si cela serait pas la solution dans quelque projets sur ton bureau. T’a deux serveurs de R&D si je ne m’abuse, alors t’a pas besoin de moi 😉

  5. Merci pour cette description des faiblesses et forces des deux produits d’un pt de vue admin sys, super intéressant !

    J’avoue que la réponse concernant ICP est un peu rude et manque nettement d’ouverture. Peut-être faudrait-il demander au garçon comment il justifie ceci…

  6. @Charles : euh, Charles, en fait, c’est Damien Pobel qui te parle ci-dessus 🙂

    Les gars de varnish ont l’air de ne pas vouloir s’acoquiner avec ICP et proposent l’alternative suivante pour mettre en place une grappe de serveurs varnish :

    – activer le hashing balancing sur le répartiteur de de charge en amont de la couche de reverse-proxies. Grâce à ce système, une page (une url unique) est toujours chargée sur le même proxy.

    En gros, tu distribue les caches plutôt que de les répliquer entre chaque serveur.

Laisser un commentaire