Comment nous préparons un site d'actualité à un pic de trafic.
Le métier d'un site d'actualité, ce sont les pics. Voici la méthode avec laquelle nous en préparons un : lire les bons logs, savoir où est le plafond, vérifier chaque tier avant de dépenser, et faire le calcul.
Dans cet article 4 sections
- Le trafic révèle des plafonds. La configuration fixe les plafonds. Se préparer à un pic, c'est les trouver avant que le public ne les trouve.
- D'abord, confirmez quel log porte réellement le trafic du site. Un log serveur par défaut peut n'en tenir qu'une petite part, tandis que le log du vhost du site lui-même tient le reste.
- Vérifiez chaque tier avant de dépenser. La base de données est souvent inactive et rapide, alors que le travail s'empile un tier au-dessus.
- Puis le calcul : les workers divisés par les secondes par requête, c'est votre vrai plafond en requêtes par seconde. Dimensionnez le pool au pic que vous atteindrez réellement, plus une marge.
Le métier d'un site d'actualité, ce sont les pics : quand l'information tombe, le public arrive d'un coup. S'y préparer est rarement une question de matériel. C'est une question de configuration : le nombre de workers, les timeouts, les logs, le cache. Voici comment nous en préparons un.
Lisez d'abord le bon log
La première discipline est de compter correctement. Sur un serveur web typique, le log par défaut et le log du vhost du site lui-même sont des fichiers différents, et le log par défaut peut ne tenir qu'une petite part du trafic. Dimensionnez quoi que ce soit depuis le mauvais log et vous le dimensionnez pour la mauvaise charge.
Sachez où est le plafond
Sous charge, les temps de requête vous disent où est la limite. La lenteur organique se disperse : quelques requêtes un peu lentes, quelques-unes très lentes. Des requêtes lentes qui se regroupent exactement au timeout de la passerelle signifient que le tier derrière la passerelle manque de workers dans son budget. C'est une signature de saturation, et elle pointe droit vers le réglage à dimensionner.
Vérifiez chaque tier avant de dépenser
Avant que quiconque n'achète de la RAM ou ne monte en gamme le tier de données, vérifiez-le. Une base de données inactive et rapide, sans requêtes lentes, qui répond à tout à l'instant où on l'interroge, n'est pas le tier à dimensionner. Le tier à dimensionner est celui dont tous les workers sont occupés. Ce schéma a son propre article dans dimensionner à la baisse, pas à la hausse.
Votre plafond, c'est de l'arithmétique
WORKERS
SEC / REQUEST
REQ / SEC
La préparation, c'est du dimensionnement, pas du shopping : le pool de workers calculé à partir du pic qu'un site d'actualité atteindra réellement, plus une marge, dans un budget mémoire par worker mesuré. Puis un tier de cache qui sert du contenu périmé quand le backend ralentit, pour qu'un backend occupé se dégrade en pages légèrement anciennes plutôt qu'en pages d'erreur. La plateforme absorbe le pic.
“Le trafic trouve le plafond que vous fixez. Fixez-le à dessein.”
Réponses directes
Pourquoi un site renvoie-t-il des erreurs 502 sous un trafic élevé ?+
En général, le tier derrière la passerelle n'a plus de workers et la passerelle abandonne à son timeout. La signature, ce sont des requêtes lentes épinglées exactement à un seul chiffre. Comptez d'abord les erreurs dans le bon log de vhost, car le log par défaut peut ne tenir qu'une fraction de votre trafic.
Combien de workers mon serveur d'application devrait-il avoir ?+
Calculez-le : les workers divisés par les secondes moyennes par requête, c'est votre plafond en requêtes par seconde. Dimensionnez pour le pic que vous atteindrez réellement plus une marge, dans un budget mémoire par worker mesuré, au lieu de faire confiance à la valeur par défaut du paquet.
La base de données est-elle le goulot d'étranglement quand le trafic monte ?+
Vérifiez avant de dépenser. Regardez si elle est inactive ou occupée et s'il existe des requêtes lentes. Souvent, la base de données est inactive et rapide, et le travail s'empile un tier au-dessus. Vérifiez d'abord chaque tier.
Comment préparer un site à un pic de trafic ?+
Faites le calcul des workers sur votre pic réaliste, confirmez quels logs portent réellement votre trafic, faites un test de charge jusqu'au plafond calculé, et placez devant un cache en mode stale-on-error pour qu'un backend lent serve d'anciennes pages plutôt que des erreurs.
Plus de trafic n'exige-t-il pas simplement plus de serveurs ?+
À terme, oui, mais presque jamais d'abord. Utilisez d'abord la capacité que votre configuration retient : des pools correctement dimensionnés, des timeouts raisonnables, un cache qui absorbe la tempête de lectures. Du matériel acheté pour couvrir un réglage de configuration est le changement de configuration le plus cher qui existe.
Vous attendez bientôt votre meilleure journée ?
Lancement, presse, pic saisonnier : apportez-nous la date. Nous ferons le calcul des workers, nous lirons les bons logs, et nous ferons du pic un graphique comme les autres.
Parler à un ingénieurVous êtes arrivé à la fin.
Mettez la lecture en pratique
Que faites-vous tourner ?
Parlez-nous de la charge de travail, du trafic et des exigences de reprise. Commencez par le configurateur de serveur, ou passez en revue les détails avec un ingénieur.
Écrit par les ingénieurs qui construisent et exploitent l'infrastructure qu'il décrit.Parler à un ingénieur