OVH Community, votre nouvel espace communautaire.

Un CDN pour le plus essentiel : les réponses DNS


ddavid
15/05/2012, 16h07
Citation Envoyé par gaboul49
Ton visiteur ne va perdre que 150ms au maximum tous les 24h comme je l'ai expliqué le post précédent.
Pour un TTL de 86400s, mon visiteur malchanceux va perdre 150 ms / 24h / FQDN utilisé, (avec des pertes éventuellement en parallèle si usage de domaines multiples). Et en supposant qu'il utilise toujours le même serveur DNS à chaque fois.

Citation Envoyé par gaboul49
Le fait que ça se produise pour 1 ou 1000 visiteurs ne change rien.
Si : si j'ai 1000 visiteurs lointains qui utilisent chacun un serveur DNS différent (improbable) dans les mêmes 24h, j'ai 100% de ces 1000 visiteurs qui perdent du temps sur la requête DNS. Et en temps total perdu : 1000 * 0.150 s par 24h pour un domaine unique.

Si j'ai 1000 visiteurs lointains, mais qu'au final ils utilisent 10 serveurs DNS différents en tout, par le biais du cache, je ne peux très bien en avoir que 1% (10 sur 1000) qui perdent du temps à la requête DNS. La plupart ne perdent alors pas de temps, Temps total perdu 10 * 0.150s par 24h pour un domaine unique.

Avec 1 visiteur lointain, c'est 100% des visiteurs lointains qui perdront les 150 ms pour un domaine unique, puisqu'il n'y a personne qui aura contribué à remplir le cache de son serveur DNS.


Citation Envoyé par gaboul49
Le DNS de ton visiteur va garder en cache ton ip pendant la durée dictée par ton TTL au moment de la mise en cache. Donc modifier le TTL au moment de modifier ton IP n'accélère pas le processus.
Je sais quand même attendre plus de 24h après être passé au TTL court pour basculer... (Autrement dit au moment de la bascule, il n'y a plus de données dans les caches avec un TTL long, donc quasiment tous les visiteurs se voient impactés en même temps par le changement du réglage.)

Citation Envoyé par gaboul49
Par rapport au gain apporté par le CDN, le fait de déporter le serveur ayant autorité sur ton domaine me parait anecdotique.
Lorsqu'on utilise plusieurs FQDNs différents par page, et que le visiteur se trouve sur une destination encore plus éloignée temporellement que Dallas (je suppose que c'est par exemple le cas en Amérique du Sud), il ne faut pas être surpris de perdre 2x200 ms=0.4s pour chaque visiteur pour lequel le cache de son serveur DNS n'a pas agi. C'est non négligeable du tout. (Je mets seulement "2x" car je présume qu'au delà de 2 FQDNs, il est très probable que le parallélisme se fasse sur les différentes latences de 200 ms.)

D'autre part, il est très fort probable que les ressources à déployer pour mettre au plus proche possible du visiteur les informations minimes contenues dans les DNS (quelques champs A typiquement) soient nettement moins couteuses que celles à utiliser pour des quantités importantes de données (pages, images, etc...). Et en plus, il serait très simple que les modifications soient répercutées sur les différents noeuds en mode push, tandis que le CDN d'OVH a plus tendance à fonctionner en mode pull.

gaboul49
15/05/2012, 15h28
Je ne comprends pas tous tes arguments :

De plus, le nombre de ms gagnées par durée de TTL est à multiplier par le nombre de serveurs DNS distincts utilisés par ses visiteurs
Non, c'est inutile. Le CDN permet une meilleure latence pour ton visiteur. Ton visiteur ne va perdre que 150ms au maximum tous les 24h comme je l'ai expliqué le post précédent. Le fait que ça se produise pour 1 ou 1000 visiteurs ne change rien.

Quand je migre du mutu vers le dédié (avec un seul serveur dédié opérationnel pouvant être cible d'une IP failover OVH), je commence par abaisser très drastiquement la durée du TTL ("DynDNS"), je bascule l'IP vers le dédié
Le DNS de ton visiteur va garder en cache ton ip pendant la durée dictée par ton TTL au moment de la mise en cache. Donc modifier le TTL au moment de modifier ton IP n'accélère pas le processus.

Par rapport au gain apporté par le CDN, le fait de déporter le serveur ayant autorité sur ton domaine me parait anecdotique.

ddavid
15/05/2012, 14h31
Bonjour,

Citation Envoyé par gaboul49
Tu veux que le serveur racine soit au plus proche de ton visiteur.
Je souhaiterais que le serveur ayant autorité mes domaines soit au plus proche de mon visiteur. (Les 13 serveurs racines étant bien là où ils sont.)

Citation Envoyé par gaboul49
Je pense que c'est inutile car dès la première requète, le DNS de ton visiteur aura ton ip en cache. Donc le gain ne se fait que sur la première requête.
Imaginons que le DNS de ton visiteur vide son cache toutes les 48h, tu vas gagner 150ms / 48h.
La durée de cache peut en effet être longue, si l'on en a décidé ainsi dans les réglages (mais avec OVH, sauf à gérer soit même son serveur, ces réglages sont plutôt soit un TTL de 86400=24h, soit un nombre restreint de secondes pour du DynDNS).

Quand un TTL est trop long et qu'il y a une panne sur un serveur, faut mieux espérer avoir utilisé une IP failover *ET* avoir un deuxième serveur prêt à prendre le relais. Et avec le failover, on ne peut pas basculer du dédié vers le mutu par exemple.

Quand je migre du mutu vers le dédié (avec un seul serveur dédié opérationnel pouvant être cible d'une IP failover OVH), je commence par abaisser très drastiquement la durée du TTL ("DynDNS"), je bascule l'IP vers le dédié, et par sécurité je laisse pendant un certain nombre de jours avant de reprendre la valeur longue normale. (Et à partir de ce moment, vaut mieux pas que mon dédié ait une panne trop longue...)

De plus, le nombre de ms gagnées par durée de TTL est à multiplier par le nombre de serveurs DNS distincts utilisés par ses visiteurs, et par le nombre de sous-domaines utilisés (encore que, les requêtes vers des sous-domaines peuvent avoir lieu parfois en parallèle).

Chez les concurrents étrangers d'OVH, Amazon semble s'être lancé là dedans avec Route 53 : http://aws.amazon.com/route53/

gaboul49
15/05/2012, 13h58
Edit : J'ai compris à la deuxième lecture.

Si le DNS de ton visiteur n'a pas en cache l'IP de ton domaine, il va aller la chercher sur un serveur racine.
Tu veux que le serveur racine soit au plus proche de ton visiteur.

Je pense que c'est inutile car dès la première requète, le DNS de ton visiteur aura ton ip en cache. Donc le gain ne se fait que sur la première requête.
Imaginons que le DNS de ton visiteur vide son cache toutes les 48h, tu vas gagner 150ms / 48h.

ddavid
13/05/2012, 23h37
Bonjour,

J'ai testé un peu le CDN pour un de mes sites, mais après avoir fait des tests pingdom aujourd'hui, je me suis posé une question assez "bête" :

Est-ce que OVH propose un service DNS également au plus près des visiteurs ?

Avec ns15/dns15.ovh.net gérant le domaine sur lequel j'ai fait mes tests, je trouve comme ordre de grandeur les temps suivants (avec pingdom) :
* 10 à 15 ms pour Amsterdam
* 70 à 80 pour New York
* 120 à 180 pour Dallas (ça commence à faire)

Je ne sais pas du tout comment pingdom fait ses requêtes DNS, mais j'ai l'impression (au vu des différents tests que j'ai pu faire), qu'ils ne se basent pas sur un serveur DNS intermédiaire faisant cache (je pense qu'ils prennent à chaque fois ce que donne ns15/dns15.ovh.net). Tandis que pour des visiteurs normaux, il y a des chances non négligeable qu'un second/n-ième visiteur bénéficie du cache du serveur DNS du FAI/de Google/d'OpenDNS/etc.

Néanmoins, si OVH proposait (ou prévoyait de proposer) un service DNS géré par un serveur au plus près du visiteur (ou du serveur DNS qu'il utilise de son côté), ça m'intéresserait de le savoir.

(NB préventif : pour éviter tout risque de confusion dans la discussion : ce topic n'a rien à voir avec le fait de régler le champ A du DNS vers l'ip 46.abc.def.ghi pour utiliser le service de CDN, ce message a pour sujet le fait que la machine renvoyant la valeur du champ A soit elle au plus près du visiteur.)