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

[sly (sylvain letuffe)]

On mardi 18 décembre 2012, Christophe Merlet wrote:
> bah si, on peut en discuter.

Je préfère donc continuer sur dev-fr

> Moi-même je ne suis pas totalement séduit par la solution actuelle
> (Cache Squid). 

Après analyse un peu plus poussée, des dizaines de graph munin passés en 
revue, je vais tempérer un peu mes doutes pour finalement dire quelque chose 
du genre :
"J'accorde que ça semble être devenu nécessaire et donc c'est une bonne chose 
pour l'OSMF de demander de nouveaux serveurs de cache compte tenu des choix 
actuels, mais j'émets des doutes sur la politique choisie envers le rendu 
standard (page d'accueil d'osm.org) et des choix techniques qui en découlent"

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.

> 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

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.

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.

charge/failure : La mise en oeuvre technique choisie du CDN ne répond à mon 
sens pas du tout ou uniquement très peu au problème de charge car yevaud et 
le point central qui génère les tuiles, et dans ce processus, ça charge 
inquiétante [1] [2] ne me semble dû quasi-exclusivement qu'a la génération 
proprement dite, pas la distribution. Créer le CDN à base de cache n'aide en 
rien pour améliorer ça, et n'apporte pas non plus de solution de replie en 
cas de pépin sur Yevaud.

BP : ça ok, le CDN aide... un peu, mais pour ça, il faut, encore une fois, 
avoir une majorité de contenu statique et très régulièrement demandé, ce qui 
n'est le cas grosso modo que pour les tuiles de zoom faible mais pas ou très 
peu pour les zoom 11 et + qui sont la cause d'une grosse partie du trafic.
[3] montre que sur un an, l'ajout de 3 serveurs de cache n'a fait que 
compenser la croissance des visites de osm.org
Bilan le problème de BP n'a même pas été amélioré ! L'endroit où les coûts de 
BP sont problématique restent problématiques !
Ça ne veut pas dire que ça n'est pas utile, on a au moins réussi à stopper la 
croissance, c'est déjà un bon point, mais je pense qu'avec d'autres 
solutions, on aurait pû régler le problème, là, on va courir après la 
croissance et on va finir par être obligé de prendre des mesures à dommages 
collatéraux.


> Mais cette solution a plusieurs avantages. C'est facile à administrer à
> distance. ça ne nécessite pas de serveur puissant, juste de la RAM (en
> 9h, 18 Go de tuiles distinctes ont été demandées). 

Je te l'accorde, mais une mise en oeuvre/maintenance aisée (encore que 
j'attends sur le long terme) qui ne sert à pas grand chose n'est pas 
forcément plus profitable qu'une réflexion amont pour ré-attribuer objectifs, 
configs et donc ressources.

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

> 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

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

[1] 
http://munin.openstreetmap.org/openstreetmap/yevaud.openstreetmap/load.html
[2]
http://munin.openstreetmap.org/openstreetmap/yevaud.openstreetmap/cpu.html
[3]
http://munin.openstreetmap.org/openstreetmap/yevaud.openstreetmap/if_eth1.html
[4]
http://tile.paulla.asso.fr/munin-osm/paulla.asso.fr/lurien.paulla.asso.fr/squid_requests.html

-- 
sly, DWG member since 11/2012
Coordinateur du groupe [ga]
http://wiki.openstreetmap.org/wiki/User:Sletuffe