[OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server

Mar 18 Déc 23:59:23 UTC 2012

C'est vrai que le gain n'est pas flagrant et en tout cas pas en vitesse
c'est même plus long qu'avant en cas de cache-miss, j'ai déjà eu plusieurs
interruptions de sessions (avec des tuiles incomplètes de taille zéro) à
cause du temps de réponse du serveur de tuile principal à répondre à son
serveur proxy Squid. Les problèmes commencent avec le zoom niveau 12 et on
a des rafraîchissements qui ne se font quasiment plus concernant les tuiles
obsolètes : il faut maintenant rafraîchir la même tuile deux fois avec
quelques minutes d'écart entre chaque pour que ce soit dispo sur le Squid
de Pau.

Certes cela soulage certainement le serveur de Londres en bande passante,
mais pas en travail à faire pour calculer les tuiles (qui du coup sont
calculées et rendues disponibles pour finalement ne jamais être utilisées
car la première requête a retourné l'ancienne version et remplis le cache
Squid à Pau qui va donc continuer aussi à retourner cette version (le truc
du "/dirty" ne semble plus fonctionner : oui il demande le rafraichissement
mais cela ne force pas l'invalidation de tuiles du serveur de Pau (sauf si
on modifie l'URL avec un paramètre GET ajouté dans l"URL des tuiles tel que
"?1", "?2" pour lui demander d'ignorer son cache et retourner la version du
serveur de Londres ; le "/dirty répété ne forcera plus non plus une
nouvelle demande au serveur de rendu et le "/status" continue alors
d'aficher l'ancien statut même si la tuile a bien été rafraichie à Londres).

Il semble que la cause de tout ça vienne de Mapnik et non de l'installation
du proxy-cache Qquid : au lieu de mettre une réponse au client en
attente sur sa session, il préfère retourner une version ancienne déjà
calculée (mais avec une durée de péremption trop longue pour cette réponse
qui ne devrait être qu'instantanée et pas recachable en aval) en attendant
pour terminer la session plus tôt (et cela pose des problèmes de cohérence
de cache, un problème qui existe depuis assez longtemps même avant l'entrée
en scène des serveurs proxy Squid). Squid ne semble pas en cause (cela
marche très bien par exemple avec Wikipédia qui parvient très bien à suivre
les mises à jour), mais bien le frontend de Mapnik (autrement dit le
serveur WMS qui lui pilote son travail à faire).

L'avantage de répondre immédiatement au client est d'économiser des
sessions en attente du côté du serveur (et donc éviter la non disponibilité
de nouveaux ports TCP pour d'autres sessions HTTP s'il y a du monde), mais
ici le problème est la non péremption immédiate (ou la péremption trop
longue) des tuiles obsolètes qui sont en attente de recalcul.

A mon avis le serveur Squid pour la France, l'Espagne ou l'Italie serait
mieux à Londres ou à Amsterdam, voire à Paris, plutôt qu'à Pau si on veut
un temps de réponse correct, étant donné que les FAI français ont tous leur
routage au départ de Paris avec un peering efficace vers Londres et
Amsterdam. Même chose pour les FAI espagnols ou italiens qui feront leur
peering efficace vers Pau en passant par Paris ou Amsterdam d'abord. Le
peering de Paris vers Pau via le réseau RENATER n'est pas foundroyant, il
n'a pas été tellement taillé pour un usage massif.

La situation serait meilleure si la Fondation trouvait un partenariat avec
des CDN mondiaux — comme Level3 qui a des serveurs proxy HTTP dans
pratiquement tous les pays, et même dans les GIX régionaux (pour les FAI
français qui ont des peerings régionaux et qui y sont directement connectés
sans faire transiter tout le trafic de leurs abonnés par Paris où se
concentre leur réseau de collecte national). Ou même avec d'autres
fournisseurs de CDN comme Google/Youtube, Amazon, Microsoft/Bing, Yahoo
(d'abord pour leurs propres services en ligne mais aussi pour leurs offres
commerciales aux sites tiers)...

La Fondation Wikimedia par exemple a bénéficié du partenariat avec Yahoo
(ou avec d'autres FAI internationaux comme Orange pour l'Europe et
l'Afrique) pour déployer des serveurs Squid correctement localisés dans le
monde avec des peerings efficaces (cela a été plus payant que de chercher à
gérer elle même des serveurs Squid à gérer elle-même), et même une
distribution gratuite pour les visiteurs (offre gratuite non décomptée du
forfait data sur un réseau mobile).

OSM France utilise une plateforme de Free qui marche bien grâce à sa
présence directe sur un GIX parisien rapide (Freeix) qui a de bonnes
connexions de peering avec la plupart des FAI français et européens.

La présence sur le GIX de RENATER ne marche bien que si les visiteurs
français passent par un FAI universitaire ou si ce sont des collectivités,
mais pas très bien pour les abonnés résidentiels (le peering gratuit d'un
FAI classique vers RENATER a une bande passante limitée et des restrictions
pour l'équilibrage des flux trop asymétriques). Sur quel GIX est connecté
le serveur de Pau, seulement RENATER ?

Le 19 décembre 2012 00:26, Christian Quest <cquest at openstreetmap.fr> a
écrit :

> Constat proche pour moi (aussi chez free), le ping est quasiment
> identique (dans les 40/45ms) et même nombre de hops.
>
> Un cache de tuile chez free Bezons diviserai mon ping presque par 2
> (23ms en moyenne sur osm11) ;)
> Le geodns pourrait-il rediriger les requêtes provenant des AS de free
> vers un serveur chez free ?
>
> Christophe, ça serait possible de rajouter ce serveur dans le munin
> d'OSM-FR ?
>
>
> Le 18 décembre 2012 23:53, Eric Marsden <eric.marsden at free.fr> a écrit :
> >>>>>> "cm" == Christophe Merlet <redfox at redfoxcenter.org> writes:
> >
> >   cm> Mais cette solution a plusieurs avantages. C'est facile à
> administrer à
> >   cm> distance. ça ne nécessite pas de serveur puissant, juste de la RAM
> (en
> >   cm> 9h, 18 Go de tuiles distinctes ont été demandées).
> >
> >   L'intérêt d'un serveur distinct de celui à Londres pour les
> >   utilisateurs français me semble discutable. Depuis ma connexion Free
> >   au domicile à Toulouse, je suis à 63 ms (16 hops) de
> >   uppa-vl10-gi0-3-0-0-pau-rtr-011.noc.renater.fr, alors que je suis à 52
> >   ms (15 hops) de me-rach.net.ic.ac.uk. J'imagine que c'est pareil pour
> >   la majorité des FAI français, qui font du peering vers Renater
> >   uniquement à Paris. Et en cas de miss la requête part quand même à
> >   Londres ...
> >
> >   Ensuite depuis mon travail (connexion Renater) je suis à 3.8ms (7
> >   hops) du serveur paulla, mais ça n'est pas très representatif des
> >   utilisateurs en général ...
> >
> >   Ceci dit, j'imagine que ça décharge un peu le lien vers Imperial
> >   College, ce qui doit leur être utile, donc merci et bravo à RedFox
> >   pour cela.
> >
> > --
> > Eric Marsden
> >
> >
> > _______________________________________________
> > Talk-fr mailing list
> > Talk-fr at openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> --
> Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20121219/78f5eaa7/attachment.htm>