Chez CrowdHandler, nous rencontrons souvent des personnes qui se préparent pour la première fois à faire face à un trafic important. Parfois, tout ce dont elles ont vraiment besoin, c'est d'une salle d'attente.
Cependant, ils mettent souvent en place des serveurs et un système d'équilibrage de charge pour la première fois eux aussi – et sont ravis d'aborder ces sujets avec nous.
Sans vouloir paraître trop dédaigneux, ce n'est pas la préoccupation principale de notre produit. Cela n'a pas vraiment d'importance pour nous, car notre produit est indépendant de l'architecture sous-jacente à la « salle d'attente ». Notre principale préoccupation est le débit de transactions que nos clients peuvent traiter.
En réalité, il est rarement envisageable d’augmenter suffisamment la capacité pour gérer un trafic 10 fois supérieur à la normale lors de pics occasionnels. Cela dit, plus votre site est optimisé, plus les temps d’attente seront courts.
La plupart des développeurs web mènent une carrière tout à fait respectable, sans jamais travailler sur des projets vraiment populaires. Ils sont donc surpris de constater qu’une grande partie des conseils présentés comme des « bonnes pratiques » ne résistent pas à l’épreuve de la réalité.
Notre expertise trouve son origine dans la création de sites web hautement disponibles pour de grandes marques du secteur des médias et du divertissement. Nous disposons donc d'une certaine expertise en matière de mise à l'échelle des sites web. Nous savons ce qui fonctionne vraiment et ce qui ne fonctionne pas.
Ce qui n'a pas d'importance
Nombre de serveurs d'applications
Vous envisagez peut-être de passer d'un serveur mutualisé à un serveur dédié. Peut-être même passez-vous d'un serveur dédié à plusieurs serveurs derrière un équilibreur de charge (que ce soit chez un hébergeur traditionnel ou via un service cloud comme AWS).
En réalité, il est rare que les serveurs d’applications soient soumis à une charge maximale ; ce chiffre n’est donc pas très significatif.
Le traitement de tâches JavaScript, PHP ou .NET pour générer du code HTML ou JSON ne mobilise pas tant que ça de ressources. Même un seul serveur peut gérer un trafic assez important.
On procède généralement à la mise à l'échelle des serveurs d'applications à des fins de redondance (pour traiter les requêtes en cas de défaillance d'un serveur). Dans les scénarios à fort trafic, les serveurs d'applications ont tendance à passer la majeure partie de leur temps à attendre une réponse, souvent de la part d'une base de données ou d'une API (qui fait office de base de données distante).
Un serveur d'applications plante généralement lorsqu'il est à court de connexions sortantes alors qu'il attend des réponses en amont. Dix serveurs d'applications bloqués en attente d'une même requête de base de données ou d'un même appel d'API ne sont pas d'une grande aide.
Ajouter des processeurs à votre serveur de base de données (BD)
Cela signifie-t-il donc qu'il faudrait commencer par examiner votre serveur de base de données ?
On utilise souvent le terme « cluster » à tort et à travers, mais à moins d’avoir intégré le sharding à votre application (jetez-y un œil), vous ne pouvez pas simplement ajouter des serveurs de base de données supplémentaires pour améliorer les performances.
Bien sûr, vous pourriez passer à une machine de base de données plus puissante, dotée d’un plus grand nombre de cœurs de processeur. Cependant, la plupart des applications modernes n’imposent pas une charge CPU importante à la base de données. Les requêtes qui vous ralentissent sont souvent limitées par la vitesse du disque (E/S) — en particulier dans les environnements cloud sophistiqués où votre stockage de base de données se trouve on ne sait où, et où l’on peut négliger la limitation des E/S jusqu’à ce qu’il faille vraiment y remédier. C’est alors que vous découvrez à quel point de véritables performances en E/S peuvent coûter cher.
Ajout d'E/S disque
Si vous analysez les temps d'exécution des requêtes sur votre serveur de base de données, vous constaterez que l'ajout de ressources CPU et d'E/S disque peut aider dans une certaine mesure, mais pas suffisamment pour empêcher le site de planter sous la charge. Doubler, voire quadrupler les spécifications de votre base de données ne sauvera pas votre site comme par magie.
Pourquoi pas ? En général, c'est parce que vos requêtes sont mal optimisées — souvent générées par un framework populaire mais inefficace — et qu'elles ne sont pas correctement indexées. En appliquant les index appropriés, vous pourriez constater que vos requêtes s'exécutent 1 000 fois plus vite. C'est bien plus rentable que de dépenser 1 000 fois plus pour votre serveur de base de données.
Une évolutivité « infinie » du cloud
Ça a l'air simple : il suffit de cliquer sur un bouton pour obtenir davantage d'exécutions, de processus ou de hamsters.
Mais même si vous maîtrisez parfaitement toutes ces configurations et que le coût ne vous pose pas de problème, si vous reposez sur des transactions (ce qui est le cas de la plupart des sites), vous rencontrerez un goulot d’étranglement au stade de la transaction — que ce soit au niveau de votre base de données (les bases de données transactionnelles ne peuvent pas évoluer indéfiniment ; renseignez-vous) ou d’un service tiers tel qu’une API de paiement (celles-ci reposent elles aussi sur des bases de données transactionnelles soumises à des limites de débit).
Ce qui compte vraiment
Mettre la page d'accueil en cache
Tu sais, cette page que tout le monde va partager sur Instagram, etc. ?
Mettre en cache.
Ne gaspillez pas les ressources du serveur en régénérant cette même page des centaines de milliers (voire des millions) de fois. S’il s’agit d’une page dynamique, rendez-la statique — ou du moins partiellement statique. Ajoutez un bouton renvoyant vers une étape distincte d’appel à l’action si les utilisateurs doivent charger l’état des stocks ou d’autres données dynamiques.
Vous ne savez pas quelle page est la plus consultée par les utilisateurs ? Découvrez-le. Il s'agit d'une donnée cruciale. Configurez vos paramètres de mise en cache et utilisez un proxy inverse (comme Varnish) ou un CDN (tel que Cloudflare), voire servez un fichier entièrement statique depuis le serveur web. Les développeurs n'apprécieront peut-être pas cette solution, mais pour les sites web qui s'attendent à des millions de visites, la mise en cache représente 80 % du travail.
Utilisez un CDN (réseau de diffusion de contenu)
Un CDN est une couche de mise en cache sophistiquée et distribuée. Même si son optimisation complète peut s'avérer délicate, il est très simple de s'y mettre. Pensez-vous que les CDN servent uniquement à diffuser des fichiers statiques dans le monde entier ?
Pas tout à fait. Bon nombre des sites les plus fréquentés aujourd’hui sont hébergés derrière un CDN, aussi « dynamiques » qu’ils puissent paraître. En réalité, ce principe est à la base de frameworks tels qu’Next.js/Vercel., qui atteignent ainsi des niveaux de performance remarquables. Mais ce n’est pas une nouveauté : les chaînes de télévision, les sites de commerce électronique et les sites de billetterie utilisent des CDN depuis bien avant votre naissance. Les nouveaux frameworks ne font que rationaliser cette approche. Voici quelques options de CDN :
- Cloudflare : abordable, très utilisé et simple à configurer.
- CloudFront : fourni avec AWS, très pratique si vous hébergez votre site sur cette plateforme.
- Akamai : l'un des pionniers, utilisé par de nombreux grands sites de vente en ligne.
Utilisez une salle d'attente
La plupart des sites web sont soumis à des limites transactionnelles qu’il est impossible de contourner. Même des géants comme Ticketmaster ont recours à des files d’attente lors des pics de ventes, alors qu’ils disposent d’un grand nombre de serveurs. Commencez par mettre en cache ce qui peut l’être, puis installez une « salle d’attente » devant les parties véritablement dynamiques. C’est une meilleure première étape que d’augmenter au hasard le nombre de serveurs dans l’espoir de répondre à la demande.
Installez un système de file d'attente, définissez un débit de transactions que vous savez pouvoir gérer, puis surveillez votre site en période de pic de trafic afin d'identifier les goulots d'étranglement réels — qui se manifestent souvent dans le journal des requêtes lentes de votre base de données ou dans les temps de réponse de l'API. Il vous suffira peut-être d'ajouter un index à une table pour résoudre vos problèmes de scalabilité. Et vous tirerez des enseignements du comportement réel du trafic, et non de tests de charge théoriques ou de conjectures.
CrowdHandler
Dans les situations où le trafic est intense, la stratégie la plus efficace ne réside pas dans une évolutivité sans limite, mais dans une gestion intelligente des ressources. Les salles d'attente jouent ici un rôle essentiel.
CrowdHandler est spécialisé dans la mise à disposition de salles d'attente virtuelles flexibles et faciles à intégrer, destinées à vous aider à gérer les périodes de forte affluence.
Inscrivez-vous dès aujourd'hui pour bénéficier d'un essai gratuit.