Il me semblait avoir vu qu'on pouvait indiquer à Windows de ne PAS maintenir le tri de l'index d'un répertoire particulier (comme il le fait par défaut), en y mettant un attribut particulier (dans ce cas, l'index devient une simple liste à parcourir du début à la fin). Pour des répertoires qui ont de très nombreux fichiers mis à jour très souvent, ce tri est plus coûteux qu'utile. Mais je ne retrouve plus l'API sur MSDN. Malgré tout, si un dossier n'est pas trié, il se pose le problème du temps de parcours en entier du répertoire avant d'y créer une nouvelle entrée (sinon il y aurait création d'un doublon), ou pour y retrouver rapidement un fichier par son nom (c'est ce que fait JTiles puisque'il n'organise pas du tout ce dossier où il stocke dans un unique dossier pour chaque fournisseur TMS toutes les tuiles de tous les niveaux de zoom et de n'importe quelle valeur de x et y). Comme JTiles est incapable de faire le ménage (il doit y avoir eu du code pour ça, mais visiblement il ne marche plus ou n'est plus activé), la seule façon de faire cela efficacement serait que JTiles divise son cache en sous-dossiers de sorte qu'il n'y ait jamais plus d'environ 2000 fichiers par sous-dossier. Comment faire ? Déjà il pourrait créer un niveau de dossier pour le niveau de zoom. Supposons la limite à entrées par dossier : le niveau de zoom 5 tient en entier dedans pour toute la planète (je suppose que les tags s'il y en a sont comptés à part, ils peuvent être aussi stockés à part dans un unique fichier index "tags"), et les niveaux 0 à 4 tiennent aussi dans cette limite. Pour le niveau 6 il faudra 4 sous-dossiers, mais le nombre de sous-dossiers va être multiplié par 4 à chaque niveau de zoom suivant. On tient jusqu'au niveau de zoom 10. Après il faudra augmenter la hiérarchie avec un autre niveau de sous-dossier jusqu'au niveau de zoom 15. Mais à la longue on a alors plein de niveaux de sous-dossiers, plus ou moins pleins, et toujours rien pour faire le ménage.
La solution est alors de stocker toujours 2048 entrées par dossier mais stocker tous les dossiers à plat en nombre fini (par exemple 256 sous-dossiers (ce qui fera tout de même 512 000 fichiers, on a de la marge pour un cache confortable !). Pour savoir dans quel sous-dossier stocker ou trouver un fichier, un simple hachage de son nom suffit ! A la suite de quoi tous les dossiers ont une taille raisonnable, ils sont maintenus très rapidement, on peut les lister de façon répétée de façon exhaustive pour y faire le ménage. Le cache peut alors se nettoyer tout seul pour respecter les contraintes de taille totale ou purger les fichiers obsolètes (les fichiers tags sont remplacés par un fichier index unique stockant les métadonnées HTTP, pas seulement les ETag, mais aussi les dates d'obsolescence si nécessaire, bien qu(on puisse aussi décider de rendre tous les fichiers obsolètes une semaine après leur création, à moins qu'on les "touche" pour les garder en faisant des requêtes HEAD au serveur) Note: sous NTFS un dossier de 2048 entrées prend 512Ko d'index dans la MFT, non compris les attributs longs ou les données de fichiers courts comme les Etags justement qui sont aussi stockés directement dans la même entrée de la MFT sans espace externe supplémentaire). S'y ajoute pour ce dossier un index de tri (sous-forme de B-arbre) qui prend en gros 128Ko (et permet des accès directs rapides à un fichier par son nom). Les suppressions ou ajouts dans un tel dossier ne demandent que peu d'I/O et pas trop d'opération en mémoire. En revanche pour un dossier de plus de 60000 entrées (fois 2 avec les fichiers Etag), cela commence à swapper énormément en mémoire et sollicite beaucoup trop les caches disques, à cause des opérations de maintenance du B-arbre (pour maintenir ses critères d'équilibre). Le 4 février 2013 23:45, Vincent de Chateau-Thierry <v...@laposte.net> a écrit : > > Le 04/02/2013 23:37, Philippe Verdy a écrit : > >> Merci mais je connaissais déjà la solution > > > C'est bien à ton mail que je répondais, mais c'était surtout une réponse à > la question de Romain. > > > vincent > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
