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

[Christophe Merlet]

Le mercredi 19 décembre 2012 à 14:40 +0100, sly (sylvain letuffe) a
écrit :

> Il s'agit donc du couplage "choix et rôle de ce rendu" impliquant "certains 
> choix techniques" que je trouve douteux pour leurs/nos choix d'avenir.
> 
> détails :
> 
> Le rôle de ce rendu standard me semble ambiguë, d'un coté, on a ceux qui 
> voudraient que ça soit un outil pour aider les contributeurs et faire vitrine 
> pour présenter "les données osm" et d'autres souhaiteraient peu ou prou que 
> ça deviennent un remplaçant direct de google maps (en terme de disponibilité, 
> mise à jour, beauté, rapidité et destiné au plus grand nombre)
> 
> La politique visant à monter un CDN tente de répondre à l'objectif deux, et 
> implique des choix techniques qui me semblent incompatibles avec l'objectif 
> 1.
> Et maintenir l'objectif 1 pénalise grandement la mise en oeuvre du CDN.

Effectivement, se plaindre de ne pas pouvoir faire un /dirty sur un
serveur de tuiles qui fournit majoritairement des tuiles au grand public
indique un mélange des genres dans l'usage du serveur.

Il faudrait un serveur de tuiles pour les contributeurs afin qu'il
puisse voir quasi immédiatement le résultat de leur travail, et un
réseau CDN pour le grand public. Chacun pouvant avoir un style mapnik
adapté.

> > Je trouve que le ratio hit/miss n'est pas fantastique mais néanmoins
> > suffisant pour décharger un peu le Master.
> 
> Yevaud, le master actuel, me semble confronté à 3 problèmes :
> - Charge trop élevée
> - BP trop élevée
> - Single point of failure

Yevaud est le générateur de tuiles. Il est effectivement tout seul pour
effectuer cette tache. Par contre il ne fait pas partie du réseau
GeoDNS, c'est Orm qui distribue la majorité des tuiles à la planète.

Cependant, Yevaud est le cache_peer des Squid du GeoDNS.

Du moins c'est ce qu'indique la doc. A cet instant dig donne d'autres
résultat...


> Bref généralités : A mon sens, un CDN de type "cache stupide" (se basant 
> uniquement sur les headers d'expiration) est fait pour distribuer du contenu 
> éminemment statique, de validité longue, et demandé avec comme base un gros 
> ratio hit/miss pas pour diminuer une charge CPU mais une BP de l'ordre de 
> 1Gbit/s et plus.

OSM ne paye pas la bande passante et n'en a pas les moyens.
Ce n'est pas une bonne idée de consommer 1 Gbs chez un sponsor avant de
décider de décharger le trafic ailleurs.

Dans le meilleur des cas, la bande passante vaut quand même 5€/mois le
Mb/s...


> On voit bien le résultat : [4] 40% de miss ! ça veut dire que dans 40% des 
> cas, et, à mon avis, dans ~80% des cas sur zoom élevés (+11) on inclus 
> latence, retard de fraîcheur dans les tuiles et donc pénalité pour objectif 
> 1) et juste un peu mieux pour l'objectif 2) partie BP
> C'est à mon sens peu glorieux pour le nombre de serveur mis en jeu, temps de 
> maintenance à y passer et risque de problèmes qui vont s'ajouter.

Je relativise le 80%.
Il ne me semble pas aberrant de penser que les internautes français
regarde en priorité les tuiles françaises, et de même pour chaque pays.
Donc grosso modo, si chaque serveur squid dessert une superficie qui 
arrive a tenir dans son cache, le ratio ne doit pas être trop mauvais.

Je vais voir s'il est possible d'avoir des stats du cache squid (accès
par pays et par FAI...).


> > Il semble que les sysadmins osm réfléchissent à d'autres solutions,
> > genre des générateurs de tuiles autonomes. 
> 
> A mon avis, pour l'objectif 2) voire l'objectif 1) c'est LA solution a 
> privilégiée, car cela réduirait tout : charge, manque de redondance, BP chez 
> nos voisins anglais.
> C'est certes plus difficile car ressources plus chères, mais ce serait à mon 
> sens largement plus efficace.

Il suffit de regarder la config matériel de Yevaud pour constater que ce
n'est pas à la portée de tout le monde.


> > Pas sûr que les internautes y gagne avec cette solution.
> Moi je pense que oui, et je fais le paris que tant que plus nous avançons vers 
> la solution CDN, pire encore pour les internautes ça va être.
> 
> (Philippe V. dans un plaisant message de lucidité, à déjà pointé du doigts 
> quelques problèmes pour l'objectif 1))
> Mais connaissant bien les options de mod_tile, je crois savoir ce qui va être 
> trifouillé sous peu, faute de ne plus avoir le choix, et qui va empirer 
> l'objectif 1) en ajoutant :
> - délais de fraîcheur plus important sur les tuiles
> - /dirty qui ne marchera que au petit bonheur la chance
> - bug de cache trop vieux persistants et aléatoires
>  
> > Mais tout compte fait, la seule vraie bonne solution à long terme est
> > que les gros consommateurs de tuiles installe leur propre serveur...
> > 
> > Tu vois quoi comme autres solutions ?
> 
> J'en vois 2 : 
> - celle que tu viens juste de citer, qui passe par une autre manière de penser 
> la carte par défaut d'osm.org et qui n'a rien avoir avec la technique (des 
> documentations toujours mieux faites, encouragement à le faire, VM toutes 
> prêtes) et communiquer sur le fait que OSM, ça n'ai pas juste osm.org, faire 
> la pub à donf pour openmapquest, inciter (férocement) à re-router du trafic 
> là bas, mettre en valeur les serveurs alternatifs et admettre que non, on ne 
> peut pas gérer la distribution à tous pour tous nous sur yevaud.
> 
> - séparer mes objectifs 1) et 2) en deux serveurs/services distincts car je ne 
> crois pas que l'on puisse couvrir 1) et 2) avec les mêmes configs

Je crois aussi

> 2) passerais sur le CDN, dont le serveur de génération principal ne serait pas 
> chez les anglais = règlement de la question de BP, de charge et presque de 
> failure, d'un coup
> 1) resterait sur yevaud



	Librement
-- 
Christophe Merlet (RedFox)
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: signature.asc
Type: application/pgp-signature
Taille: 198 octets
Desc: This is a digitally signed message part
URL: <http://lists.openstreetmap.org/pipermail/dev-fr/attachments/20121219/c14bf42e/attachment.pgp>