[OSM-talk-fr] Vider le cache des tuiles Bing & Mapnik

[Philippe Verdy]

J'aurais même envie de proposer que le module JTiles ne stocke plus
rien du tout en cache, car on peut le remplacer par une requête à un
proxy cache local :

Oui car :
- il existe bien Squid pour Windows qui gérera efficacement le cache
et le gardera sous contrôle (il peut même stocker son cache sous forme
compressée, mais cela demande un peu plus de travail du processeur).
- JOSM peut être paramétré pour faire ses connexion internet via un
proxy : il n'y a qu'à utiliser ici alors un serveur local
http://127.0.0.1:8000/ (si le serveur Squid local est configuré pour
écouter le port TCP 8000)
- il existe d'autres utilitaires sous Windows (je ne vais pas en
donner la liste) implémentant un proxy cache "transparent" qui sera
utilisé alors pour filtrer les accès par TOUS les navigateurs ou
applications clientes, et leur donner alors un cache commun : ces
applications (comme les navigateurs) n'ont plus alors qu'à être
paramétrées pour que leur cache soit réduit au strict minimum, par
exemple le cache IE par défaut est *beaucoup* trop grand lui aussi,
prenant par défaut plus de 20% de l'espace libre du disque dur où est
stocké le profil utilisateur ce qui peut faire là encore des dizaines
de gigaoctets, cependant il sait aussi faire le ménage des fichiers
obsolètes et prévenir aussi le remplissage excessif du disque dur).
Certains de ces utilitaires proposent avec des filtres contre les
bandeaux de publicité, certains cookies traceurs (bien que ces
fonctions soient plutôt assurées maintenant par les antivirus qui
mettent en place eux aussi leur propre proxy transparent.... mais
malheureusement sans gestion d'un cache web paramétrable pour les
requêtes HTTP)

Il ne me semble pas que Squid sous Windows puisse être paramétré comme
un cache complètement transparent (car HTTP 1.0, contrairement à HTTP
1.1, n'oblige pas un navigateur à effectuer sa requête HTTP avec un
paramètre "Host:", et certains services web ne sont pas en HTTP 1.1 ;
si le proxy est utilisé comme cache transparent, il devra alors
écouter tous les adresses IP pour les requête HTTP à filtrer, ce qui
nécessite des privilèges spéciaux et l'installation du cache en tant
que filtre intégré au pare-feu des interfaces réseaux, et que ces
interfaces soient activées pour utiliser le pare-feu...)

En attendant le cache JTiles de JOSM ne tient aucun compte des
paramètres HTTP standard de gestion du cache (comme "Cache-Control:"
et les dates d'expiration). C'est à mon avis encore une ébauche juste
faite un peu dans l'urgence pour éviter de trop solliciter les
serveurs TMS juste en "glissant" la carte, et pour que le glissement
de la carte ou le zoom avant puis arrière puisse réafficher rapidement
les tuiles déjà chargées juste avant avec une réactivité suffisante.

L'idée d'utiliser un proxy cache local (mais externe à l'application)
serait une solution, mais l'application JOSM saura toujours mieux
qu'un proxy comment elle compte utiliser le cache et ce qu'il est
pertinent ou pas de garder en cache (Squid par exempel va garder en
cache plus de choses parmi les métadonnées, JTiles ne conserve
actuellement QUE les ETag). Et c'est pour ça qu'il faudrait
l'améliorer pour qu'il gère son cache de façon plus intelligente et
sans avoir à recourir à l'installation d'un cache externe sur un poste
client. Si on veut que JOSM soit simple à utiliser pour tout le monde,
JTiles doit pouvoir tourner nativement et automatiquement sans que les
utilisateurs n'aient à le désactiver ni à faire la purge eux-même de
son cache local.

A ce sujet, j'ai commencé un bout de code destiné à remplacer le code
Java existant : comme je l'ai expliqué j'utilise pour le stockage une
série de sous-dossiers (jusqu'à 256, arbitrairement, bien que les
navigateurs web souvent n'en utilisent que 4), et en stockant les
fichiers d'après l'URL complète de la ressource mise en cache, et en
déterminant le numéro de sous-dossier à utiliser dans le cache avec un
simple hachage de l'URL. String.hash() semble suffire, même si on
pourrait utiliser un hachage plus efficace encore (MD5 est très
rapide) pour distribuer plus équitablement les fichiers dans les
sous-dossiers du cache.

Dans ce cas, il y aura un cache commun pour TOUS les serveurs de
tuiles, tous les niveaux de zoom, et une gestion de type LRU pour
aider à faire le ménage et garantir un volume plafond de stockage
(Cela sera très utile pour les utilisateurs de tablettes par exemple,
dont le stockage local est limité car sans disque dur mais avec un
petit SSD de 32 Go pour TOUTES les applis et l'OS !)

Le code fera aussi attention à éviter de prendre toute la place libre,
il aura un seuil minimum d'espace libre à garder sur le disque (je
pense que ce sera par défaut quelque chose comme le plus grand parmi:
1 Go (?) ; 2% de la taille totale du volume ; 5% de son espace libre
au moment du test ; ces valeurs par défaut sont à étudier avant même
d'offrir un moyen de les régler dans l'UI des préférences) et qu'il
s'obligera à faire plus de ménage si ce n'est plus le cas, même si
cela veut dire que le cache local sera beaucoup plus petit que la
taille maximum prévue initialement (idéalement il devrait alerter
l'utilisateur quand le cache local ne peut plus contenir un minimum de
l'ordre de 32 Mo car JOSM devrait alors télécharger trop de tuiles :
cette alerte peut aider l'utilisateur à faire le ménage ailleurs sur
son disque).

Le 5 février 2013 07:16, Romain MEHUT <romain.mehut at gmail.com> a écrit :
> Merci pour ces réponses très détaillées ;)
>
> Et bientôt je me poserai sans doute aussi la question pour Linux.