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