Latence et CDN

La latence est une des composantes qui pénalise le plus les performances actuellement. Les connexions Internet françaises se font plutôt à haut débit, et même un mauvais wifi laisse finalement passer assez de trafic pour que ce soit viable. Par contre, avec l’explosion du nombre de composants par page, la latence est probablement le facteur le plus limitant. 40 composants à 50ms de latence, c’est 2 secondes de perdues. Même en imaginant utiliser deux fils de téléchargement, c’est encore une seconde d’attente. Sur une mauvaise connexion (wifi ?) ou quand on s’adresse à un site qui n’a pas de serveur en France (ou très proche), la latence peut vite exploser.

Je ne parle même pas de ce que pourraient nous apporter HADOPI et LOPSI2 s’ils filtrent les accès côté FAI (on peut leur faire confiance pour affirmer que les débits ne bougeront pas, mais en ce qui concerne la latence…). À 120ms de latence c’est d’un coup plusieurs secondes qui partent en fumée. En fait ce sont souvent les publicités qui ont la plus grande latence. Quand le javascript qui gère la pub est bloquant et qu’on a deux ou trois redirections HTTP, on peut facilement perdre une seconde. Si vous ne me croyez pas, regardez l’exemple de Right Media.

Les solutions

Pour aller plus vite il faut donc soit avoir moins de composants par page, soit faire en sorte que la latence entre ces composants et le visiteur est réduite. Moins de composants c’est renouveler des solutions que j’ai déjà abordé ici : mettre en cache tout ce qu’on peut, container les fichiers javascript, faire de même avec les feuilles de style, et explorer les sprites CSS pour les images. Réduire la latence elle-même est par contre plus complexe. Comme on ne peut pas d’un coup de baguette magique améliorer la connexion du visiteur (quoi que certains tentent de jouer avec TCP), il ne reste plus qu’à approcher le serveur au maximum près du fournisseur d’accès du visiteur.

Pour un public français c’est réalisable, les FAI français font du peering entre eux, tout est regroupé entre quelques gros, la latence due au placement géographique est probablement proche de zéro (pour un site américain, avoir des serveurs sur les deux côtes au lieu d’une seule fait une réelle différence par contre). Sauf qu’assez souvent ce n’est pas un site français c’est un site francophone, ou adressé aux français (qui sont peut être en déplacement). Reste que même pour un site non touristique qu’on croit adresser aux français métropolitain, il y a des requêtes qui viennent des DOM TOM, des pays limitrophes, des pays européens (oui, je travaille tous les jours de Paris avec une adresse IP londonienne ) et finalement d’un peu partout dans le monde (je suis toujours étonné de voir les statistiques géographiques de ce blog).

Content Delivery Network

L’idéal serait donc d’avoir un serveur local chez chaque FAI. Malheureusement on se doute bien qu’au niveau coûts c’est infaisable, d’autant plus s’il faut les synchroniser. Les CDN, puisque c’est comme ça que ça s’appelle (Content Delivery Network, réseau de distribution de contenu), se placent à quelques endroits géographiques, avec des liens réseaux spécifiques vers les FAI principaux et entre les différents emplacements. Amazon propose donc quatorze emplacements, huit aux USA, quatre en Europe (Londres, Dublin, Amsterdam et Francfort), ainsi que deux en Asie (Hong Kong et Tokyo). Akamaï, le leader, propose 71 pays différents (et probablement plusieurs emplacements aux USA).

Dans l’ensemble sur les CDN donnant des listes précises, les pays du nord et les USA semblent les mieux couverts mais ce peut être un biais du à mes sources d’information. N’ayant pas eu à faire de recherche spécifique  l’Asie l’Afrique ou l’Europe ont peut être quelques CDN spécifiques. À vous de fouiller dans la cinquantaine de CDN dans le monde. Akamaï propose une petite application pour constater la latence entre deux villes. Bon, c’est visiblement très biaisé, mais le principe est bien là, lui.

Fonctionnement

Sur le principe un CDN ce n’est pas bien compliqué. Il s’agit de modifier le DNS pour faire pointer vers celui du CDN. Là on utilise des DNS personnalisés chez différents FAI, ou un système de tracking géographique des adresses IP pour renvoyer les différents utilisateurs chacun vers le serveur le plus proche de chez eux. Le serveur lui même est soit pré-rempli avec tous les composants utiles, soit fonctionne comme un proxy évolué (ce qui demande que vous même gériez correctement toutes vos entêtes de cache).

Dois-je utiliser un CDN ?

Pour un petit site français, pas certain. Pour un site plus gros, cela peut permettre de déporter les coûts de serveurs et de bande passante, c’est uniquement une question financière. Par contre, dès que vous visez plus international, en dehors de la simple Europe occidentale, ça peut commencer à prendre son sens. Les coûts sont assez progressifs et abordables même pour une petite société (Akamaï part à partir de 150$/mois, Amazon a un prix au consommé qui semble ridicule pour des petits trafics).

Une seule chose, ne vérifiez pas l’efficacité depuis votre bureau français, avec une faible latence. Au mieux entre un CDN avec un serveur à Paris et votre propre serveur parisien, il n’y aura pas grande différence. Il se pourrait même que le CDN semble ralentir vos pages (vu qu’il faudra peut être joindre Londres pour certains réseaux). Par contre pour d’autres, aux DOM TOM ou à l’étranger, la différence sera notable. Un petit coup par webpagetest peut donner un premier aperçu si vous le souhaitez.

Au pire, rien ne vous empêche de fournir un lien directement vers votre serveur quand le visiteur est dans la même zone géographique, et un lien vers le CDN sinon. Une petite reconnaissance de l’adresse IP devrait suffire et le risque de dégrader les performances en cas d’erreur est assez faible.

Une réflexion au sujet de « Latence et CDN »

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>