Varnish hit-ratio

Closermag, Nabilla et cache http

Le vendredi 7 novembre 2014 du fait de l’actualité people autour de la starlette Nabilla la plateforme hébergent le site Closermag.fr que j’administre enregistre +63% de requête supplémentaire. Je parle bien de requête http et non pas de visiteur unique qui est une donnée commercial qui ne représente en rien l’effort de production. Quand au page vue … elles sont constituées de plusieurs requête http d’un nombre variable, donc je n’utilise pas non plus cette mesure.

Il en ressort que le cache http est correctement configuré couplé avec l’utilisation de varnish  est une solution puissante pour absorber les pics d’audiences

Le challenge est la gestion des images. La photo à une part importante dans la mise en page et la ligne éditorial de closermag.fr . En conséquence les images sont nombreuses et de taille importantes. Différent choix ont été fait :

  • Isoler leur distribution dans un silo dédié basé sur varnish en frontend et nginx en backend. Le varnish bien que disposant d’un cache mémoire important de 8Go ne peux contenir l’intégralité des images, en conséquence avec nginx nous assurons son alimentation de façon performante.
  •  Les images de design du site on une durée de validité pour mise en cache d’une journée et celle d’illustration d’une année. Nginx ajoute des entêtes d’instruction du cache http.
  • Nous avons en outre fait le choix d’utiliser de multiple sous domaine afin de paralléliser les appels au maximum et de contourner les limites de certains navigateurs
  • Les images sont traitées afin d’en limiter le poids par la suppression des données Exif . Dans le processus d’alimentation en photos de Closermag l’utilisation de nombreux logiciel avait tendance à hypertrophier le volume de ces données.

Le 7 novembre 2014 un unique serveur varnish a assuré :

  • Un taux de réponse de 95% avec son cache, donc seul 5% des requêtes on du être demandé au backend ngnix.
  • Le pic de bande passante  de 149,91 Mb/s.
  • La réponse à une moyenne de 2660 req/s

6 réflexions sur “ Closermag, Nabilla et cache http ”

  1. Allez hop, c’est mieux que sur twitter 😉

    Tu mets toujours les images dans Varnish (en regardant rapidement les headers). Tu les sers juste via nginx après le lru_nuked ?

    Parce-que j’ai cru comprendre que tu servais directement les médias sans Varnish, ce qui est une pratique de plus en plus répandue, pour ne pas surcharger le cache.

    Ce n’est pas forcément fou, car les serveurs web en Event ( comme nginx, apache 2.4) sont très performants et consomment peu.
    Par contre, cela implique la duplication des médias en local, car les servir depuis un NFS serait un goulot d’étranglement en terme d’I/O

  2. Servir les assets directement via Nginx est loin d’être déconnant, d’ailleurs peut être même très conseillé.

    L’open_file cache permet d’économiser des précieux I/O, surtout sur un « slow filer ».

  3. Oui je place toujours les images dans le cache varnish depuis un backend nginx. Le flux de distribution des images est donc nginx -> varnish (spécial ressources statique) -> internaute.

    Un autre silo apache avec un varnish dédier s’occupe du php. Le flux de distribution du html est donc apache -> varnish (spécial html/php/ESI) -> internaute.

    Le storage (au sens eZ) de closermag.fr (eZ 4.7) est sur NFS via une petite baie EMC. Le volume est de 325 Go environs.

    Les frontaux php et le nginx on tous accès au partage NFS. Les images sont déposées via le backoffice propulsé par les frontaux php et elles sont accédé par le nginx.

    Ngnix est le backend de varnish (spécial ressources statique) et distribue toute les images appelées via les domain prefix (img1, img2, css1, etc.)

    Mais Ngnix est aussi backend de varnish (spécial html/php/ESI) et distribue toute les images appelées via le www (historique, backlink, seo tout ça).

    Les frontaux php comme l’unique nginx sont des machines virtuelle vmware. Le hosting en machine virtuel conduit à utiliser des disques virtuels, trèèèèès lent pas nature. Localiser un si gros volume d’images, sur tout les frontaux et le nginx, garder cela cohérent, à jours et performant en I/O est une impasse.

    Dans toute l’architecture Closermag seul le varnish (spécial ressources statique) est un serveur reposant sur un hardware dédié (un vieux Xeon E5606 4 core avec 10Go de ram) dont les 4 interfaces réseau sont agrégées en bonding 802.3ad.

  4. Oui ce n’est pas le même FQDN, si tu regarde les header http des différent appel http tu t’en rend compte de la présence de silos

Laisser un commentaire