Le 28 juin 2012 08:37, Marc Sibert <[email protected]> a écrit : > N’hésites pas à rafraichire le cache du navigateur (shift - mise à jour de > la page sur firefox). Il existe aussi une procédure permettant de forcer le > recalcul d'une tuile côté serveur, mais c'est rarement nécessaire. > > http://c.tile.openstreetmap.org/18/133039/90247.png/status (donne l'état de > la tuile) > http://c.tile.openstreetmap.org/18/133039/90247.png/dirty (force le refresh)
Dommage qu'on n'ait pas la même chose (au moins la sous-page "/status") sur les autres serveurs de tuiles hors ceux ici de Mapnik. De même le framework OpenLayers ne tient pas compte de l'état du cache web affiche de façon indéfinie des images obsolètes récupérées d'anciennes versions stockées dans le cache, même lorsque le navigateur a chargé une nouvelle version des tuiles. (On s'en rend compte en faisant un click droit pour ouvrir une tuile dans un nouvel onglet, pour ensuite l'y rafraîchir avec F5, mais quand on revient à la page OpenLayers, on a beau bouger la page ou même la recharger, c'est encore l'ancienne version qui s'affiche et non celle remise à jour pourtant séparément dans le cache du navigateur ! Le seul moyen d'afficher une nouvelle version est de vider complètement le cache du navigateur (en fermant d'abord la page) ce qui est carrément contreproductif quand on veut voir l'effet d'une modification (par exemple juste après une correction). Au moins on n'a pas ce problème de rafraîchissement avec les autres frameworks. Mais OpenLayers est une collection de scripts particulièrement complexes qui génère du code Javascript effectuant apparemment ses requêtes HTTP lui-même sans passer par les fonctions de chargement web du navigateur, et gérant d'une façon étrange le stockage dans le cache (ou qui ne tient pas compte des dates d'obsolescence): il génère alors un cache local absolument énorme contenant des tonnes de tuiles obsolètes qui ne sont même pas purgées. D'ailleurs ce problème de croissance incontrôlée du cache local de tuiles existe aussi dans JOSM qui fait croitre de façon démesurée le cache avec des tuiles qui ne sont ensuite plus jamais purgées (on se retrouve alors avec un répertoire cache contenant vite dans un seul dossier des dizaines de milliers de fichiers (à ne surtout pas stocker dans un volume FAT, NTFS est très hautement conseillé sinon ça rame de plus en plus ! Mais même avec NTFS on constate que finalement le cache devient vite plus lent au moindre accès que simplement redemander les tuiles au serveur). Je veux bien qu'il y ait une politique pour les tuiles, seulement un serveur de tuiles indique une date d'obsolescence raisonnable, et le protocole HTTP pourrait être respecté quand une tuile est rafraichie, afin que le client en tienne compte ! Si la solution c'est de vider le cache du navigateur à chaque fois, pour restaurer les performances et éviter d'encombrer indéfiniment un volume disque, ces logiciels clients doivent être mis à jour (c'est la principale cause actuellement des plantage de JOSM, qui rapidement ne parvient même plus à lire en entier les fichiers de son cache local de tuiles, tellement il y stocke de fichiers, même en version 64 bits avec une taille de VM imposante, par exemple 8 Go). Enfin les logiciels qui gèrent des caches de tuiles devraient éviter de stocker des dizaines de milliers de fichiers dans un même dossier du système de fichiers. Si les fichiers ont des noms bien définissables, on doit pouvoir calculer une clé de hachage simple mais prédistible de ces noms permettant de les répartir en par exemple un maximum de 256 dossiers de 256 sous-dossiers maximum (ou toute division suffisante adaptée au niveau de zoom de ces tuiles selon le serveur), afin d'accélérer considérablement l'accès et la maintenance de leurs contenus, comme aussi accélérer considérablement le nettoyage (surtout sur les volumes FAT ou NFS ou UFS qui n'ont pas d'index d'accès direct, les fichiers étant trouvés dans un dossier en le parcourant depuis le début, ou le dossier étant maintenu trié et demandant de plus en plus de maintenance au fur et à mesure que le nombre de leurs entrées croit). Si on devait aller plus loin, même les métadonnées pour les tuiles devraient non pas être dans des fichiers texte séparés pour chaque tuile mais dans un index de base de données locale (sur un volume NTFS, ces métadonnées peuvent être stockées dans des streams sans entrée supplémentaire dans les dossiers, ces streams étant eux aussi autoindexables en B-arbres paginables avec un accès direct très rapide aussi bien en lecture qu'en mise à jour, sinon on peut aussi utilise un fichier de base de données unique dans le dossier des images; si cette base de données est corrompue ou plus à jour, il peut être reconstruit en ignorant et purgeant automatiquement aussi les images du dossier sans métadonnées; la base de données doit uniquement contenir les champs d'entête MIME pertinents pour la gestion du cache HTTP et émis par le serveur, indépendamment des dates et noms utilisées localement pour le stockage des images). Mais je me demande dans tout ça à qui demander de revoir la gestion défaillante des caches locaux de tuiles dans JOSM et OpenLayers, qui sont les seuls logiciels qui jusqu'à présent ne permette pas une automatisation de la purge selon une politique raisonnée. A cause de cela, je suis obligé d'utiliser un logiciel de proxy cache externe transparent, et de demander au navigateur et à JOSM de réduire au minimum ses caches locaux afin qu'ils interrogent systémtiquement le proxy cache externe transparent (qui lui au moins respecte les politiques HTTP émises par les serveurs); sans cela, cela finit rapidement par ralentir totalement le système hôte et peur provoquer trop facilement des anomalies et pertes de données ou corruptions et bloquages au niveau système à cause des trop nombreux fichiers stockés en vrac dans un même dossier au contenu trop instable et sans cesse croissant. _______________________________________________ Talk-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-fr
