<div dir="ltr"><div class="gmail_extra">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 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).</div>


<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">Le 18 décembre 2012 23:53, Eric Marsden <span dir="ltr"><<a href="mailto:eric.marsden@free.fr" target="_blank">eric.marsden@free.fr</a>></span> a écrit :<br>


<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">>>>>> "cm" == Christophe Merlet <<a href="mailto:redfox@redfoxcenter.org" target="_blank">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><span><font color="#888888"><br>--<br>Eric Marsden<br></font></span><div><div><br><br>_______________________________________________<br>


Talk-fr mailing list<br><a href="mailto:Talk-fr@openstreetmap.org" target="_blank">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><br></div></div></blockquote></div></div></div></div>