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

[Philippe Verdy]

Le 19 décembre 2012 16:58, Christian Quest <cquest at openstreetmap.fr> a
écrit :

> Le 19 décembre 2012 16:52, Christophe Merlet <redfox at redfoxcenter.org> a
> écrit :
> > 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.
>
> Je ne crois pas car le  serveur avait déjà un problème de raffraichisement
long et de gestion des caches et que ce problèmes est maintenant aggravé :
on risque d'attendre maintenant TRES longtemps l'invalidation des tuiles
fraiches dans le cache.

Le /dirty permettait juste d'interroger l'état d'une tuile pour savoir où
en en est mais aussi pour faire d'autres varifications visuelles (par les
contributeurs).

Il n'empêche qu'on voit trop souvent les simples utilisateurs se plaindre
que la base n'est pas à jour, et si on leur dit « vide le cache de ton
navigateur, c'est déjà corrigé » cela ne marchera pas non plus selon le
cache Squid via lequel on visualise les cartes, puisque cela reviendra
seulement à recharger les tuiles du cache Squid en question et pas celles
du serveur de tuiles principal.

Il y a bien un truc pour forcer Squid à aller chercher une nouvelle tuiles
c'est de lui ajouter une pseudo-requête "?1" dans l'URL des tuiles, mais
même s'il le fait, cela ne raffrichaira pas son cache local des tuiles
chargées SANS cette requête ajoutée (pour l'utilisation normale où on
"navigue" sur la carte et on affiche plein de tuiles en passant aussi d'un
niveau de zoom à l'autre. Bref cela ne peut servir qu'à une vérification
ponctuelle car après ça, meˆme si on vide son cache de navigateur pour
recharger la page normalement, on rechargera le contenu pas à jour du cache
Squid.

La gestion des dates de péremption des tuiles retournées par le serveur à
Squid ou à un navigateur reste un problème encore non résolu (et pour
lequel demander aux utilisateurs de vider leur cache local est
CONTRE-productif puisque cela revient à leur demander de passer outre la
tentative de réduction de bande passante mise en place justement avec un
cache du côté des serveurs. Les sites d'afffichage de rendus OSM devrait
fonctionner sans qu'on n'ait JAMAIS besoin de vider un quelconque cache à
la demande (que ce soit celui de son propre navigateur ou par un "truc"
destiné à forcer le passage au travers du proxy-cache Squid, ou celui d'un
FAI, notamment les serveurs cache des FAI mobiles et dont OSM n'a
absolument pas le contrôle).

Si vous vouelz une preuve de ce non-fonctionnement des dates de péremption :

- visualisez une zone de la carte pour remplir votre cache de navigateur
(ou celui de votre éditeur préféré comme JOSM).
- envoyez une modif au serveur
- essayez de rafraichir la page du navigateur ; rien de changé n'apparait
- essayez de vider le cache de votre navigateur : rien de changé n'apparait
- vérifiez le statut d'une tuile avec un clic droit du navigateur pour
n'aficher qu'une tuile sans le framework HTML/Javascript qui n'a chargé :
rien n'apparait
- raffraichissez spécifiquement cette tuile toute seule : rien n'apparait
- utilisez le "/dirty" et patientez quelques minutes pour que le "/status"
indique le changement de date
- revenez à la tuile toute seule : toujours rien (alors que le serveur
indique que cette tuile a été réfénérée (il va falloir atetndre encore des
heures pour que Squid fasse disparaître de son cache cette tuile et surtout
que ni vous ni personne d'autre ne la redemande pendant ce temps-là
- maintenant si cette tuile toute seule est fait apparzitre la
modification, revenez à l'affichage normal de la carte (dans sont framework
HTML/JAvascript) : la tuile bien rafraichie quand on l'affiche toute seule
ne l'est plus dans la carte !
- c'est seulement à ce moment-là qu'on peut vider le cache de son
navigateur pour forcer cette fois le rafraichchissement des tuiles chargées
par le framework HTML/Javascript normal (car ce framework ne charge pas les
tuiles de la même façon qu'une simple visite du navigateur sur l'URL d'une
seul tuile : les requêtes effectuées par le framework en Javascript ne sont
pas similaires, il y a des paramètres manquants tels que les "Accept=*",
les cookies, et la session et d'autres qui dépendant du paramétrage du
navigateur mais non pris en compte par le Javascript qui ne fait pas des
visites normales, certains de ces paramètres ONT une influence sur la
validité du contenu du cache du navigateur, et notamment les "Accept=*"
tels que "Accept-Language: fr, en;q=0.5").

Et ce dysfonctionnement est maintenant encore plus sérieux avec un Squid en
plus dans la chaine : on a des tuiles qui ne se rafraîchissent JAMAIS sur
le serveur Squid (surtout celles des premiers niveaux de zoom, les plus
souvent revisitées).
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/dev-fr/attachments/20121219/d5168d4e/attachment-0001.html>