Quel hébergement pour un site à fort trafic

Certains liens de cette page sont des liens d'affiliation : si vous souscrivez après avoir cliqué, nous percevons une commission, sans surcoût pour vous. Cela ne change ni notre classement ni nos réserves, qui reposent sur les caractéristiques réelles des offres. En savoir plus

Quand un site grandit, le réflexe est de prendre un serveur plus puissant. C'est souvent la solution la plus coûteuse et la moins efficace, parce qu'elle finance un gaspillage plutôt qu'elle ne le corrige.

Ce guide propose l'ordre inverse : mesurer, optimiser, puis dimensionner, en franchissant les paliers d'architecture un par un plutôt que de sauter directement au plus complexe.

Ce que « fort trafic » veut dire techniquement

Le nombre de visites mensuelles est un mauvais indicateur, et c'est pourtant celui que tout le monde utilise. Deux sites recevant cent mille visites par mois peuvent solliciter leur serveur dans un rapport de un à cent.

Ce qui compte réellement, ce sont trois autres grandeurs.

• Les requêtes simultanées. Cent mille visites étalées sur un mois représentent environ deux visites par minute. Les mêmes concentrées sur deux heures après un passage média représentent plusieurs centaines de requêtes par seconde.
• La part de requêtes non cachables. Une page servie depuis le cache coûte quelques millisecondes. La même générée dynamiquement peut coûter cent fois plus.
• Le poids des données transférées. Un site qui diffuse des vidéos ou des fichiers volumineux sature sa bande passante bien avant son processeur.

Optimiser avant de dimensionner

C'est l'ordre qui fait gagner le plus d'argent, et c'est presque toujours celui qu'on inverse. Payer un serveur trois fois plus puissant pour compenser un site qui gaspille dix fois trop de ressources revient à financer le gaspillage.

• Le cache de pages au niveau du serveur, qui sert le HTML sans exécuter le code applicatif. Gain typique : un facteur dix à cent sur les pages publiques.
• Le cache d'objets, qui garde en mémoire les résultats de requêtes en base et allège les pages non cachables.
• Un réseau de diffusion de contenu pour les images, scripts et fichiers statiques, qui décharge le serveur de l'essentiel du volume transféré.
• L'optimisation des images, souvent le premier poste de bande passante, et le plus simple à corriger.
• Le nettoyage de la base de données, encombrée par les données laissées par les extensions désinstallées.

Ces cinq actions coûtent peu et suffisent fréquemment à faire tenir sur un hébergement modeste un site que l'on croyait condamné à migrer.

Les paliers d’infrastructure

Quand l'optimisation a été faite et que la charge reste trop élevée, la montée en infrastructure suit une progression assez régulière.

Chaque palier ajoute du coût mais surtout de la complexité d'exploitation. Passer directement au palier 4 pour un site qui tiendrait au palier 2 revient à créer des problèmes que l'on n'avait pas.

Séparer la base de données : le premier vrai saut

C'est l'étape qui apporte le plus de bénéfice pour la complexité ajoutée, et elle est souvent négligée au profit d'une simple montée en puissance du serveur.

Sur un serveur unique, le serveur web et la base se disputent le processeur, la mémoire et les entrées-sorties. Sous charge, ils se ralentissent mutuellement : le web attend la base, qui attend le disque saturé par le web.

Isoler la base sur sa propre instance supprime cette contention et permet de dimensionner chaque composant selon son besoin réel. Une base managée ajoute en prime les sauvegardes automatiques et la restauration à un instant donné.

Anticiper un pic annoncé

Passage média, campagne publicitaire, opération commerciale : quand le pic est prévu, il se prépare, et cela change tout par rapport à un pic subi.

• Tester la charge à l'avance en simulant le trafic attendu sur un environnement identique à la production. C'est le seul moyen de connaître son point de rupture avant de l'atteindre.
• Vérifier le taux de cache et forcer la mise en cache des pages qui recevront le trafic.
• Monter temporairement d'offre quelques jours avant, puis redescendre. La plupart des hébergeurs le permettent sans réinstallation.
• Prévoir une page de secours statique, très légère, à activer si le serveur sature : mieux vaut une page dégradée qu'une erreur serveur.
• Surveiller en direct pendant le pic, pour réagir plutôt que de découvrir le problème le lendemain.

Pour aller plus loin

• Serveur dédié
• Hébergement cloud
• Tester la vitesse de son hébergement