Les secrets de Nursit pour tenir 1.3 Millions de visites en 24h

, par Ben., Cédric

Cette semaine, un site SPIP hébergé par Nursit a connu un buzz impressionnant sur un article d’actualité : plus de 1.3 millions de visites en 24h. Ébouriffant !

Notre client, tout étonné à la fin de la journée, de s’exclamer :

Un grand bravo et merci pour le gestion de la journée ! C’est impressionnant. A vrai dire, je ne pensais pas qu’on pouvait tenir une telle charge, ni qu’un buzz pouvait générer autant de visites.

Levons le voile sur les secrets d’une telle performance, ce qui contentera aussi sûrement les curieux qu’on a pu lire parfois sur IRC : J’aimerais bien connaître leur secret, à Nursit, pour avoir des sites si rapides

Les serveurs

Au départ de Nursit, nous nous sommes posés plein de questions. Quelle infrastructure choisir pour tenir notre objectif de proposer un hébergement performant, sûr, et à un prix abordable de SPIP comme un service ?

Pas de Cloud

Nous avons évalué des solutions Cloud, parce que, forcément, il ne faut pas mourir idiot. Mais après quelques mois de benchmark, nous sommes arrivés aux conclusions suivantes :

  • Le cloud, c’est du disque réseau, scalable, donc (très) lent ;
  • Le cloud, ça revient cher pour une ressource donnée quand on compare au prix de location de la même ressource physique en direct ;
  • Le cloud, c’est flou : on achète une « disponibilité de ressources », mais du jour au lendemain la performance de votre infra peut changer du simple au double sans aucune explication.

Forts de ces constats, nous avons opté pour une approche beaucoup plus traditionnelle : louer des machines physiques et mettre en place des outils qui nous permettent très facilement de répartir nos sites entre les machines, de les déplacer d’une machine à l’autre, de les backuper en toute fiabilité. Ainsi, nous gérons nous-mêmes l’allocation de nos ressources physiques, en toute connaissance.

Des serveurs qui tiennent la route

Ne pas chipoter sur le matériel ! Nous avons regardé quel est le goulet d’étranglement en terme de performance : c’est très facile, c’est le disque dur. Donc, sans hésitation, nous utilisons depuis le départ des serveurs avec disque SSD. C’est plus cher, mais tellement plus rapide. Montés en RAID 1 pour la sécurité. Et Backupés automatiquement chez un autre fournisseur de serveur, dans un autre datacenter, dans une autre ville (se prémunir contre l’incendie d’un datacenter, la faillite d’un prestataire, l’explosion nucléaire - hum).

La configuration

Pas d’exotisme dans nos choix, que des outils éprouvés que nous prenons le temps de configurer finement.

Serveur Web

Une classique couche Apache + mod_php. Nous confions l’OpCode caching à XCache que nous utilisons sans soucis depuis très longtemps.

Applicatif

Nous mutualisons le code de SPIP : tous les sites d’un serveur utilisent le même noyau PHP qui n’est donc chargé qu’une seule fois dans le cache OpCode (et qui est donc toujours dans le cache, même pour un site peu visité, ce qui accélère le premier hit sur un site à froid).

Reverse Proxy

Du Varnish en frontal du serveur web, configuré finement en fonction de SPIP (grandement inspiré de http://zzz.rezo.net/Varnish) avec un choix un peu original pour le caching des pages dynamiques : le contenu public est caché pendant 60s par Varnish. Ainsi, pas de difficulté de configuration des temps de cache, pas d’effet de bord indésirable de cache qui colle, de client qui ne voit pas son contenu à jour, etc...
Mais en cas de gros coup de bourre, cela limite ce qui passe vers le serveur web : on a un tamis à gros trou qui laisse passer en direct le petit trafic, mais retient le gros trafic.

Pour tous les fichiers statiques par contre, du classique, Varnish cache en fonction du Expire.

HTTPS

Depuis le début de l’année, tous les sites hébergés chez Nursit bénéficient automatiquement du HTTPS sur les noms de domaines branchés sur le site, et les formulaires de Login et l’espace privé sont systématiquement servis en HTTPS.
Pour cela, nous avons industrialisé la gestion de certificats avec Let’sEncrypt.

Et pour servir le HTTPS, nous avons remis une couche d’Apache en proxy devant Varnish, comme point d’entrée puisque Varnish ne sait pas le gérer.

Le monitoring

C’est LE secret. Surveiller, détecter les anomalies de fonctionnement, mettre en place un palliatif automatisé à chaque fois que c’est possible.

En pratique, quand on regarde de près l’activité d’un serveur web, on s’aperçoit qu’une très grande partie de son activité consiste à servir des robots d’indexation (parfois très mal codés, robot.dlweb@ina.fr si tu nous écoutes…), des robots de hack, des robots de SPAM et des abuseurs qui httrackent des sites.
Et pendant qu’il sert ces hits, le serveur web n’est pas disponible pour servir les utilisateurs humains qui souhaitent consulter le site.

Nous avons donc mis en place des mécanismes pour prioriser les utilisateurs sur les robots, en reprenant la décharge automatique de l’écran de sécurité SPIP et en la complétant par une détection améliorée des robots.

Nous repérons, par exemple, les IP qui ont une consultation abusive d’un ou plusieurs sites, et nous les déclarons temporairement comme des robots. Pendant ce temps, elles pourront voir normalement le site, mais si jamais le serveur connaît une surcharge temporaire, elles seront invitées à revenir plus tard en recevant une erreur 503.

Autre point important du monitoring : connaître à chaque instant les ressources consommées par chaque site pour savoir qui a besoin d’un coup d’un seul sans prévenir de plein de ressources.
Souvent, c’est un bug dans lequel est tombé un robot, ou un abus. Que l’on corrige aussitôt, soit dans l’applicatif, soit en amont.

Un exemple concret mais si fréquent : les pages HTML bugguées qui contiennent un lien vers elle-même mais avec une URL bugguée qui garde les & en &. Puis && au hit suivant et ainsi de suite. Un vrai piège à bots qui s’épuisent à parcourir un nombre infini d’URLs pour indexer le site. Seule solution : les arrêter tout de suite. Dans ce cas, par exemple, si un robot demande une URL avec &&, on lui envoie immédiatement une erreur 403 pour ne pas épuiser le serveur, coupant court à toutes ses divagations.

Nous monitorons aussi tous les hits PHP longs, les requêtes lentes MySQL, les boucles lentes de SPIP. Cela nous permet de remonter aux URLs et squelettes fautifs,et selon les cas, soit d’indiquer le problème au client pour qu’il le corrige, soit de le corriger par nous-mêmes.

Toutes ces dispositions nous permettent de ne pas gâcher bêtement des ressources et de les conserver disponibles au maximum pour servir les utilisateurs.
On peut voir ça comme une gestion écologique de nos ressources.

La connaissance de SPIP

La connaissance parfaite de SPIP nous permet aussi de faire travailler de concert le serveur et l’applicatif.

Par exemple, la détection des floodeurs (IP qui consultent le site de manière compulsive et suspecte) est faite par SPIP, et le traitement (prise en compte des IPs qui sont traitées comme des Bots) et fait par le serveur avec une tache cron et un prepend PHP.

Ou encore les mécanismes antispam de SPIP sont pris en compte niveau serveur pour kicker les bots spammeurs en amont et éviter de lancer le moteur de SPIP pour faire ça.

La gestion du cache SPIP repose sur le plugin Memoization. Mais nous avons mis en place un stockage redondant du cache : XCache + disque. Cela nous permet de le servir rapidement depuis XCache, mais de ne pas tout perdre quand on reload apache. Dans ce cas, le cache est repris depuis le disque, puis remis dans XCache par l’applicatif.

En plus du plugin Memoization, nous imposons aussi l’installation et l’utilisation de certains plugins qui favorisent la performance (CacheCool) ou la sécurité (NoSpam) du site.

Pour l’antispam, justement, nous avons mis aussi en place une collecte centralisée des spammeurs : quand un bot (ou un humain pugnace) commence à spammer un ou plusieurs sites que nous hébergeons, cela remonte sur notre plate-forme qui voit son activité globale et le détecte. Tous les sites SPIP qui utilisent le plugin NoSpam récupèrent cette information et peuvent repérer le spammeur à son arrivée. Ainsi les petits malins qui postent consciencieusement un message par site sont aussi bien repérés que les posteurs compulsifs sur un seul site.

Alors ?

Alors, quand vers 12h l’article de notre client a commencé à buzzer, les alertes ont sonné chez nous.
Un coup d’œil au monitoring nous a permis de voir que nous n’avions pas affaire à un bot mais à du buzz, et que notre configuration du nombre de process apache était un peu trop prudente.

PNG - 20.8 ko

Comme le (petit) serveur (4 cœurs 32Go de RAM) pouvait tenir plus, on a ouvert les robinets en passant de 512 à 1024, puis 2048 le nombre de process maxi. En pratique, cela s’est stabilisé un peu au dessus de 1024.

Et puis, nous avons sorti le pop-corn et compté avec notre client les visites tout le reste de la journée. Plus de 900 000 à la fin de la journée (en 12h donc), plus de 1.3Millions en 24h.