Discussion :

[Gordon Fowler]

OVH lance une offre de Content Delivery Network
Pour rapprocher les sites Internet de leurs visiteurs


Lorsqu'un internaute désire consulter un site web, ses requêtes sont dirigées vers le lieu où ces pages sont stockées. Plus le visiteur est éloigné de cet espace d’hébergement, plus le temps de latence peut être long.

C‘est pour remédier à ce problème et optimiser ces délais, que OVH vient de lancer une offre CDN (Content Delivery Network). Les webmasters peuvent ainsi héberger tout ou partie de leurs contenus sur ces nœuds et diminuer les temps d’accès à leurs pages. « Leurs sites sont également mieux référencés dans les moteurs de recherche, qui prennent en compte ce critère de rapidité », ajoute l’hébergeur.

Sept CDN sont déjà actifs : Paris, Milan, Madrid, Amsterdam, Londres, Francfort et Varsovie.

Quinze autres seront disponibles au cours du 1er trimestre 2012, aux États-Unis (Ashburn, Atlanta, Chicago, Dallas, Los Angeles, Miami, Newark, New York, San José, Seattle, Palo Alto), au Canada (Toronto), en Chine (Hong Kong), au Japon (Tokyo), ainsi qu’à Singapour.

L’offre CDN est actuellement en phase de bêta test. L’accès est gratuit et ouvert à tous. Que les sites soient hébergés chez OVH.com ou par un autre prestataire.



Source : OVH

Et vous ?

Intéressé(e) par une telle offre ?

[Tepane]

J'utilise Cloudflare depuis bientôt un an.
Mes domaines et serveurs sont chez OVH.
J'étais partant pour faire le test, mais je me suis vite arrêté.

En effet, lors de l'inscription, OVH propose de modifier les dns d'un domaine ... entier.
Chez Cloudflare, je n'ai eu qu'a changer les DNS d'un sous domaine (cdn.xxx.com), sans rien toucher aux autres sous domaines.

Je veux bien le retour d'autres utilisateurs, et voir si ils proposent les mêmes services que Cloudflare (protection contre les attaques, statistiques ...)

[nouknouk]

N'étant pas trop versé dans le domaine, j'ai du mal à comprendre comment les pages peuvent être hébergées dans des sortes de mirroirs répartis à peu près partout sur la planète alors que de nos jours quasiment chaque page web contient une partie dynamique, dont le contenu varie donc en fonction de l'utilisateur.

Ou alors seules certaines parties de la page sont hébergées de façon décentralisée (genre les images) ?

[vingt sens]

@nouknouk Après une petite lecture sur le site d'OVH, il semblerait que ce soit bien les contenus statiques qui sont seuls dupliqués.

http://www.ovh.com/fr/cdn/

Diffusez les contenus statiques comme les images, scripts, feuilles de style...

Lorsqu'un visiteur arrive sur votre site, CDN charge immédiatement les contenus statiques tels que les images sur static : <img src="static.votre-site.tld/images/..." />

Cette méthode d'utilisation, idéale pour les sites vitrines ou peu chargés en dynamique

[grunk]

N'étant pas trop versé dans le domaine, j'ai du mal à comprendre comment les pages peuvent être hébergées dans des sortes de mirroirs répartis à peu près partout sur la planète alors que de nos jours quasiment chaque page web contient une partie dynamique, dont le contenu varie donc en fonction de l'utilisateur.

Ou alors seules certaines parties de la page sont hébergées de façon décentralisée (genre les images) ?

Les CDN servent à diffuser les contenus statique du type image , css , javascript...
Il y'a deux intérêts principaux :
- Paralléliser le chargement des ressources sur une page ce qui n'est pas possible si tout est sur le même domaine
- Servir les données d'un serveur proche de l'utilisateur pour gagner un peu sur la latence et donc le temps de chargement de la page.

Les moteurs de recherche étant sensible à la vitesse de chargement d'une page, entre deux sites identique , celui avec des cdn devrait être mieux référencé que l'autre
Les pages en elles même (php,jsp,html) reste bien évidemment sur le serveur "principal"

[marts]

Je ne suis pas vraiment convaincu de l'intérêt de ce système.
Dans la mesure où les contenus statiques sont déjà mis en cache par les navigateurs, il n'y a qu'à la première visite sur un site que la différence peut être significative.

[nouknouk]

Merci pour vos précisions

[gcsti]

Client d'OVH depuis longtemps donc plutôt satisfait puisque je le reste, je suis toujours très prudent avec les annonces de nouveaux produits : les conditions d'utilisation (contraintes, changements à apporter pour tester...) ou la disponibilité qui reste très aléatoire en font des produits incompatibles avec un semblant de mise en production même limitée (dernier en date le fameux HubiC qui se veut concurrent de DropBox mais en plus généreux, dont le fonctionnement n'est pas encore à la hauteur de ce qui est annoncé). Sans parler des documentations dont la mise à jour suit la mise en place des produits avec un délai certain...
Donc nouveaux produits c'est bien, continuez OVH ! mais du point de vue de l'utilisateur il vaut mieux malheureusement ne pas trop contribuer et laisser les autres faire le test sous peine de passer beaucoup plus de temps que prévu.
La volonté d'être un fournisseur pour les geeks est-elle encore un avantage pour les clients aujourd'hui au regard des ambitions de part de marché ?

[pomeh]

Hello !

En voilà une bonne initiative (de plus) de la part d'OVH ! Les CDN et les performances web en général ont le vent en poupe ces derniers temps et selon moi c'est une excellente nouvelle.

Pour ceux qui douterait de l'intérêt des CDN, voici quelques uns de leur nombreux avantages:
- ils permettent de distribuer des contenus statiques de manière performante,
- les serveurs sont répartis un peu partout sur le globe et le visiteur utilisera automatiquement le serveur le plus proche de chez lui, réduisant significativement le temps de réponse,
- ils sont cookies-free, c'est à dire qu'ils n'envoient pas les informations de cookies dans les en-têtes de la requête, réduisant de quelques octets le poids de la ressource (les cookies n'ont pas de sens dans un fichier .css),
- pour préciser ce que disai grunk, ils permettent d'augmenter le parallélisme de téléchargement des ressources, car la page web sera distribuée depuis au moins 2 serveurs (celui de base + le CDN), et en augmentant le nombre de serveurs on augmente le nombre de requêtes pouvant être effectuées en parallèle,
- ils sont généralement optimisés pour que les fichiers restent longtemps en cache (de l'ordre de l'année), ce qui n'est pas toujours le cas des serveurs "non CDN",
- ils permettent d'améliorer la vitesse de chargement de son site de manière presque magique, sans avoir à configurer soit même son serveur (ce qui en plus, n'est pas toujours possible pour les personnes),
- en séparant le chargement des fichiers statiques depuis un CDN, le serveur "principal" n'a plus besoin de les servir, donc sa charge de travail diminue, la bande passante utilisée aussi; bref, ses performances sont aussi améliorées,


Un exemple d'utilisation des CDN est l'inclusion dans une page Web d'une libraire Javascript telle que jQuery. Une bonne pratique est d'inclure le fichier depuis les serveurs de Google via une adresse du type "https://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js". Ici, il s'agit déjà d'un CDN, donc ce sera (généralement) plus performant que si vous hébergé le fichier sur votre propre serveur. De plus, dès qu'un visiteur se rends sur un site A faisant référence à ce fichier, ce dernier sera mis en cache; désormais, si le visiteur se rends sur un site B totalement indépendant (ou non) du site A, et que le site B fait également référence à ce fichier, alors le fichier sera directement récupéré depuis le cache navigateur et il n'aura même pas besoin d'être téléchargé à nouveau. Sachant que cette technique est assez répandue, le gain réel (en temps et donc en argent) n'est pas négligeable...

Je ne suis pas vraiment convaincu de l'intérêt de ce système.
Dans la mesure où les contenus statiques sont déjà mis en cache par les navigateurs, il n'y a qu'à la première visite sur un site que la différence peut être significative.

Pour répondre à marts, tu as en partie raison seulement. En effet lors de la première visite, le cache sera vide donc le CDN sera entièrement utilisé. En revanche, le CDN sera également utilisé et utile lors de la mise à jour de tes fichiers statiques, et dans le cadre d'un site maintenu régulièrement, les mises à jour sont plutôt fréquentes.
Sinon, en matière de performances Web, il est généralement très mauvais de considérer que "la première visite ne compte pas" (j'exagère volontairement le trait). La première visite constitue la première impression du visiteur, c'est le premier avis qu'il va se faire sur le site, si sa première expérience est mauvaise ou dégradée, il est possible que le visiteur n'ai plus envie de revenir sur le site. Pour t'en convaincre, essayes de noter ta première réaction lorsque tu visites un site pour la première fois: que penses-tu lorsque le site est lent ? C'est frustrant. Et pour informations, une étude a été menée l'an dernier sur le site de Yahoo, et les statistiques ont montrées que 70% des visiteurs avait un cache vide. 70%, ça laisse rêveur...


Pour ceux que ça intéressent, voici une liste de liens autour des CDN et des performances Web en général:
- une liste de CDN http://www.cdnplanet.com/cdns/
- un CDN zéro configuration http://www.coralcdn.org/
- une collection de librairies hébergées sur un CDN Javascript http://www.cdnjs.com/#/search/#all
- initiation WPO [ame="http://www.slideshare.net/kennydee/initiation-webperf-comprendre-analyser-et-optimiser-les-performances-web-frontend"]Initiation Webperf : Comprendre, analyser et optimiser les performa...@@AMEPARAM@@ssplayer2.swf?doc=confrencewebperffinale-110507110505-phpapp02&amp;stripped_title=initiation-webperf-comprendre-analyser-et-optimiser-les-performances-web-frontend@@AMEPARAM@@confrencewebperffinale-110507110505-phpapp02@@AMEPARAM@@initiation-webperf-comprendre-analyser-et-optimiser-les-performances-web-frontend[/ame]
- pourquoi les performances Web sont importantes http://www.yottaa.com/optimization/w...ze-performance
- ma liste de liens autour des performances et CDN http://delicious.com/pomeh/WPO http://delicious.com/pomeh/CDN
- un retour d'expérience intéressant http://www.codinghorror.com/blog/201...a-feature.html , à noter la citation:

Now, I would not recommend going directly for a CDN. I'd leave that until later, as there are a bunch of performance tweaks on Yahoo's list which are free and trivial to implement. But using a CDN has gotten a heck of a lot less expensive and much simpler since 2007, with lots more competition in the space from companies like Amazon's, NetDNA, and CacheFly. So when the time comes, and you've worked through the Yahoo list as religiously as I recommend, you'll be ready.

[morgan59]

les CDN existent depuis pas mal de temps et ont bien prouvé leur utilité :
- protection contre DoS
- cache du contenu statique pour accélérer l'accès aux applications
Akamai vend ce service depuis pas mal de temps déjà

[topdawg]

Client d'OVH depuis longtemps donc plutôt satisfait puisque je le reste [...]
Donc nouveaux produits c'est bien, continuez OVH !

En voilà une bonne initiative (de plus) de la part d'OVH !

Je suis étonné de voir l'opinion positive dont bénéficie OVH alors qu'ils sont incapables d'assurer le service qu'ils ont annoncé. PHP+MySQL, ça me paraît le minimum syndical sur le web depuis de nombreuses années. Et même ça, ça ne marche pas!

Guess what? La solution qu'ils proposent, au lieu de prendre 30 secondes pour mettre la configuration d'équerre: prendre un SQL privé et payer au minimum le triple du prix de l'hébergement déjà payé.

Au lieu de multiplier les "initiatives", ils devraient déjà faire que les choses les plus basiques marchent comme elles devraient. Avec les sprites, la compression et le fait que beaucoup de contenu est maintenant dynamique, je trouve un CDN complètement inutile. Mais ce n'est que mon avis.

Quant à ceci…

Un exemple d'utilisation des CDN est l'inclusion dans une page Web d'une libraire Javascript telle que jQuery. Une bonne pratique est d'inclure le fichier depuis les serveurs de Google via une adresse du type "https://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js".

Je rigole doucement parce que je ne vois pas en quoi c'est une bonne pratique d'aller chercher un fichier – dont le contenu peut très bien avoir été altéré – de quelques centaines de ko sur un serveur qui sert des dizaines de milliers (voire plus) de requêtes du même genre ? Google a des sous, des serveurs dont les performances font rêver, et des systèmes géolocalisés, mais ils ne contrôlent pas le nombre de requêtes qui leur arrive et ils n'ont pas une baguette magique-sirène-gyrophare pour vider l'autoroute et faire passer leur contenu ultra-urgent.

Vérification faite, jquery.min.js pèse 33.186 octets, dixit Opera, à peu près 32 ko… C'est peanuts, même sur la plus lente des lignes adsl.

Qui n'a jamais vu googleapis ou google analytics ou yahoo ui dans la barre d'état de son navigateur ? Moi j'ai fait cette expérience; c'est pourquoi je sers mes fichiers depuis mon site, lequel gère aussi les statistiques. Autre raison, aller chercher du contenu sur d'autres sites ou serveurs multiplie les risques de panne, ce qui aura au final l'effet inverse de celui recherché. Mais bon, ce n'est que mon avis, hein ?