johanBleuzen

La dernière soirée WebPerf m'avait énormément plu, je connaissais tous les sujets mais je le avais appronfondis et j'avais rencontré des gens intéressants que je m'étais empressé de suivre sur Twitter. Pour cette seconde soirée, je ne connaissais pas les problématiques de latence et les CDN, mais je dois dire que je suis reparti ravi de ces présentations tout en améliorant mes connaissances sur ce sujet assez vaste et très technique...

Comme la dernière fois, une joyeuse troupe de webdev c’est réuni dans les locaux d’Octo sur les Champs Elysées et c’est Eric Daspet qui a introduit la soirée avec une petite introduction sur la latence réseau.

La latence réseau

Pour cette introduction, Eric Daspet met l'accent sur le fait que les performances dépendent également du réseau de l'utilisateur final. Par exemple, plus l'utilisateur est loin du serveur du site, plus la latence va avoir un impact sur la perception de rapidité d'un site. Sachez que pour faire un aller retour Paris -> Sidney, il faut en théorie 100ms. En pratique cette valeur appelée Round Trip Time (temps d'Aller Retour) est beaucoup plus important, il peut monter jusqu'à 500ms lorsque les conditions réseaux sont moins bonnes. Donc on ajoute encore 100ms en plus si vous êtes derrière un réseau d'une grosse entreprise ou si vous vous connectez sur un mauvais Wifi... Bef pour chaque requête, il faut ajouter au minimum 100ms dans les temps de transfert, ce qui allonge le temps de chargement du site. On le voit très bien sur cette capture, ou le vert représente les temps réseau (DNS, connexion, attente, transfert) :

On voit très clairement que l'on passe la majorité du temps de chargement à attendre après le réseau. Ce qui veut dire, plus il y a de requêtes HTTP à faire, plus le temps de chargement augmente avec la latence. Donc un petit conseil, optimisez au maximum le nombre de requêtes de vos pages...

Il termine sa présentation avec des explications qui me rappellent les cours de réseaux avec des graphiques de transits de paquets TCP et les conclusions suivantes :

• la bande passante optimale est 5Mbps,
• plus le RTT diminue, plus la page se charge vite,
• plus le temps de RTT est grand, plus faible sera le débit.

Les CDN sont capables de fournir un service qui va faire permettre de diminuer le RTT pour les utilisateurs du monde entier...

Le Content Delivery Network par Cedexis

Julien Coulon, co-fondateur et manager général (?) de Cedexis, nous a fait la présentation la plus technique de la soirée. J'espère que je ne ferai pas de bourdes dans ce retour, si jamais c'est le cas dites le moi et je corrigerai...

L'objectif de la présentation était de savoir ce que l'ont peut faire pour les CDN d'un point de vue internaute. En effet, les utilisateurs finaux qui téléchargent les médias à partir d'un CDN peuvent avoir des problèmes de performances, mais comment remonter l'informations aux site et informer les utilisateurs qu'ils peuvent télécharger le même contenu sur un autre CDN.

La société est toute récente, elle est opérationnelle début 2010, ces fondateurs ont compris l'intéret d'une telle technologie lors de l'élection américaines ou Obama utilisait déjà 6 CDN juste pour sa campagne électorale. Julien nous a raconté comment le, enfin la première cliente de sa société Cedexi n'est autre qu'une certaine Carla... Fini pour les détails "people", on entre dans le vif du sujet.

Cedexis propose aux entreprise de monitorer les performances des CDN d'un point de vue utilisateur final, c'est une sorte d'aggrégateur de performances de CDN. Il suffit d'insérer un script JS sur le site du client qui va faire des mesures de performances puis les envoyer vers le "Radar" de Cedexis pour permettre de monitorer toutes les performances en temps réel. Malheureusement je n'ai pas de capture de bonne qualité mais la home de la startup donne un petit apercu de l'application de monitoring.

Sans rentrer dans les détails, aujourd'hui les éditeurs de contenus ont plusieurs solutions pour utiliser des CDN, soit elles passent par Akamai (un des leaders des CDN avec plus de 70000 serveurs dans le monde), soit elles passent par des CDN déployé par les différents FAI qui sont proche des utilisateurs finaux. Ainsi cela permet en théorie de garantir qu'un utilisateur free dispose du même débit qu'un utilisateur Orange.

Car ce n'est pas forcément le cas en utilisant des CDN internationaux, en effet les FAI ont les moyens de bloquer ou limiter les débits des utilisateurs sans qu'ils ne s'en aperçoivent. Du coup, les gens pensent que le site est lent alors que c'est le réseau de leur FAI qui pose des problèmes. Julien a présenté l'exemple de France Télévision, ou ils ont diminué de 17 secondes le temps d'affichage des vidéos (et des pubs), en conséquence 6 fois plus de vidéos sont visualisés.

Avec leur outil Radar qui agrège les données de performances, tout le monde est gagnant. Du coté des éditeurs de contenu, plus d'affichages égal plus de chiffre d'affaire et pour les utilisateurs garantie d'avoir les meilleurs performances. En utilisant un CDN, on peut gagner 20% en performance de temps de chargement, ce qui représente 10% d'augmentation du nombre de vues, soit 360 000€ sur un an de revenu en plus, toujours avec l'exemple de France Télévision.

En conclusion de la présentation, il faut retenir que leur outil est au plus près du client, donc il est vraiment une source d'amélioration des performances pour l'utilisateur et qu'un service de CDN ne peut pas :

• être disponible partout, pour tout le monde, en même temps
• garantir la performance et la disponibilité pour tout le monde
• être le plus compétitif commercialement

Le retour d'expérience du site LeParisien

La troisième et dernière présentation a été faite par Didier Crosse qui est le responsable technique de la plateforme web du Parisien. C'était une excellent présentation de retour d'expérience d'amélioration d'une plateforme et d'utilisation des CDNs. Bref, c'était intéressant, technique, parfois rigolo car il ne manque pas d'humour et tout cela malgré une voix défaillante (disait-il...).

Comme tout bon retour d'expérience, il fallait faire un point sur la situation de départ et elle n'était pas fameuse. En 2008, ils ont une plateforme développée par une société externe qu'ils appellent la grosse boite noire, ils ne savent pas forcément comment elle marche mais ils savent qu'elle coute cher... En 2008, lors des élections municipales, le site tombe et reste indisponible pendant 5 jours. C'est une éternité sur internet...

Cette interruption a été la goutte qui a poussé au changement. Récupération du code en interne avec une petite équipe de développeur avec des objectifs bien définis :

• faire une infrastructure minimale,
• pouvoir gérer une charge très supérieur,
• avoir un cout le plus faible possible,
• améliorer les temps de réponses,
• gérer la consommation de bande passante

Pour atteindre ces objectifs, un soin particulier a été apporté aux sources JavaScript, CSS (diminution du poids des CSS par 22 !!!), HTML, le code PHP a également subi des optimisations.

Didier a même présenté la politique de cache du site, qui n'est absolument pas aggressive. Les fichiers statiques (HTML/JS/CSS) sont cachés pendant 1 minutes, les images le sont pendant 3 minutes et le contenu dynamique est caché pendant 1 heure. On peut être surpris de ces valeurs, mais elle reflète le besoin de la presse d'être réactif et encore plus sur internet. Donc une "breaking news" doit pouvoir se retrouver sur la home de chaque navigateur le plus rapidement possible...

Je ne sais pas si tous les objectifs ont été atteints mais Didier semblait particulièrement fier du travail accompli et il y a de quoi... Aujourd'hui Google met 3 secondes pour indexer chaque nouvelle page publiées, les couts de fonctionnements ont été divisés par 2, avec l'utilisation des CDN ils peuvent gérer très facilement leur contenus médias et les performances pour l'utilisateur final... En plus Didier nous a donnée beaucoup de chiffres fort impressionnants.

Temps de chargement :

• Avant : 11 secondes
• Après : < 4 secondes

Amélioration du traffic mensuel:

• Visiteurs Uniques Avant : 280 000
• Visiteurs Uniques Après : 5 000 000 (mesure réalisée avec un outil différent)
• Pages Vues Avant : 400 000
• Pages Vues Après : 2 200 000

Qualité de service (QoS) :

• Taux de disponibilité Avant : 87%
• Taux de disponibilité Après : 99,99%
• Temps de traitement serveur Avant : >4 secondes
• Temps de traitement serveur Après : >1 secondes

En conclusion de ce retour d'expérience Didier donne des arguments qui plébiscitent l'utilisation des CDN tel que Cedexis (comme de par hasard ;) ). Cela leur a permis de maintenir un temps de réponse minimal, avec une haute disponibilité de leur contenus et de respecter leur couts.

Conclusion

Merci de m'avoir lu jusqu'ici, encore un pavé mais il y avait tellement à dire. Bref, encore une très bonne soirée avec trois présentations intéressantes et qui ont une forte valeur ajoutée pour les développeurs web et responsables techniques. Personnellement, j'ai préféré la troisième présentation car j'apprécie les retours d'expérience et parce que les chiffres obtenus par les améliorations faites au site du Parisien sont tout simplement impressionnants.

Mais la présentation qui m'a le plus amené à réfléchir est celle de Julien Coulon ou j'ai vraiment compris comment la netralité pouvait être atteinte.

Je vous conseille de vous inscrire à la prochaine soirée qui devrait avoir lieu début 2011 sur un sujet qui n'est pas encore défini, mais qui, je suis sur, me fera encore découvrir plein de choses...

Les slides de la soirée :

• Présentation des initiatives locales et introduction à la latence par Eric Daspet,
• Cedexis, gestion et monitoring des CDN par Julien Coulon,
• Retours d'expérience LeParisien.fr par Didier Cros.