50
Derrière bon nombre de décisions en matière d’hébergement se cache une idée reçue : il suffit de choisir suffisamment de ressources CPU et de RAM pour que le serveur semble rapide. En termes de puissance de calcul brute, c’est vrai. Mais en ce qui concerne la rapidité perçue par l’utilisateur de votre service, ce n’est souvent pas le cas. Cette perception dépend en grande partie d’un facteur qu’aucune mise à niveau ne peut résoudre : la distance physique qui sépare votre serveur de vos utilisateurs.
C'est ce qu'on appelle la latence, et il est important de bien la comprendre avant de choisir votre hébergeur.
La distance, c'est du temps, et la physique en fixe la limite minimale
Les données ne voyagent pas instantanément. Elles se déplacent dans la fibre optique sous forme de lumière, et la lumière dans le verre se propage à environ deux tiers de sa vitesse dans le vide, soit environ 200 000 km par seconde. Cela semble suffisamment rapide pour être négligeable, jusqu’à ce que l’on se souvienne que le signal doit aller et revenir à chaque requête.
Un aller-retour entre des villes proches peut ne prendre que quelques millisecondes. Les liaisons longue distance et intercontinentales peuvent faire grimper la latence aller-retour à plusieurs dizaines, voire plusieurs centaines de millisecondes, selon les emplacements et le tracé du réseau. Aucun processeur, aussi rapide soit-il, ne peut changer cela. On ne peut pas contourner la vitesse de la lumière par le calcul.
Où cela se ressent-il concrètement ?
Un surcroît de 80 ms sur une seule requête peut passer inaperçu. Le problème, c’est que les applications modernes effectuent rarement une seule requête.
Le chargement d’une seule page peut impliquer des dizaines d’allers-retours : le code HTML, puis les ressources auxquelles il fait référence, puis les appels d’API, puis les requêtes de base de données qui les sous-tendent. Chacun d’entre eux subit le « coût de la distance ». Cumulez-les, et un site hébergé sur le mauvais continent paraîtra lent d’une manière qu’aucune puissance de serveur, aussi importante soit-elle, ne saurait expliquer.
À qui cela s’adresse-t-il principalement ?
Toutes les charges de travail ne sont pas sensibles à la latence ; il convient donc d’identifier clairement les cas concernés.
Les services en temps réel et interactifs en font les premiers les frais. Jeux en ligne, appels vidéo, outils de collaboration en direct, plateformes de trading : tout ce qui implique qu’un utilisateur attende une réponse dans l’instant. Dans ce cas, quelques dizaines de millisecondes font la différence entre une expérience fluide et une expérience frustrante.
Viennent ensuite les applications web interactives et les API. Un tableau de bord qui envoie de nombreuses petites requêtes, ou une API que d’autres systèmes appellent en séquence, multiplie l’impact de chaque milliseconde de distance.
Les tâches en masse et en arrière-plan sont les moins concernées. Si vous exécutez des tâches par lots, des sauvegardes ou un site essentiellement statique derrière un CDN, l’emplacement physique a beaucoup moins d’importance.
Ce que l’emplacement ne résout pas, et ce qu’apporte un CDN
Un CDN est utile, mais il est important d’en connaître les limites. Un réseau de diffusion de contenu met en cache les fichiers statiques à proximité des utilisateurs, de sorte que les images, les scripts et les feuilles de style arrivent rapidement depuis un nœud périphérique proche. C’est une réalité et cela s’avère utile.
Ce qu’un CDN ne rapproche pas, c’est la logique de votre application et votre base de données. Les parties dynamiques, celles qui prennent des décisions et lisent les données, s’exécutent toujours là où se trouve votre serveur. Pour une application dynamique, c’est toujours le serveur d’origine qui effectue la majeure partie du travail que l’utilisateur attend.
Choisir un emplacement, en pratique
La règle est simple : placez le serveur près des personnes qui l’utilisent le plus. Si votre audience se trouve principalement en Europe, un centre de données européen offrira généralement une latence réseau inférieure à celle d’un serveur situé de l’autre côté de l’océan. Le matériel a toujours son importance, mais il ne peut pas supprimer la distance physique entre le serveur et l’utilisateur.
Lorsque vos utilisateurs sont répartis dans différentes régions, la vérité est qu’aucun emplacement n’est idéal à lui seul. Vous choisissez l’emplacement le plus proche de votre groupe le plus important ou le plus sensible à la latence, et vous utilisez un CDN pour la couche statique afin d’atténuer les problèmes ailleurs.
INTROSERV propose des serveurs en Europe, en Amérique du Nord, en Asie et en Australie, avec des sites notamment à Francfort, Londres, Amsterdam, Naaldwijk, Beauharnois (Canada), Singapour et Sydney, ce qui vous offre davantage d’options pour implanter votre infrastructure au plus près de vos utilisateurs.
Conclusion
L’emplacement n’est pas un détail que l’on optimise en dernier. Pour tout ce qui est interactif, il constitue la base sur laquelle reposent toutes les autres optimisations. Un emplacement bien choisi peut avoir un impact plus important sur une application interactive qu’une mise à niveau matérielle qui laisse le chemin réseau inchangé.
Avant de comparer les processeurs, posez-vous d’abord cette question plus simple : où se trouvent mes utilisateurs, et à quelle distance se trouve le serveur par rapport à eux ?
