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 _______________________________________________ dev-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev-fr
