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

[Philippe Verdy]

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 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).



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
>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20121219/8ef51454/attachment.htm>