En plus mon serveur local n'a pas de "table d'inodes" puisque son stockage est sous Windows. Le tuning est tout à fait différent, même si c'est du RAID (que j'ai monté en stripes de 64 Ko classiques). Je n'ai pas encore tenté d'augmenter la taille des tuiles stockées (cela demanderait une modif du serveur pour qu'il en retourne des fragments de 256x256 au lieu de la tuile stockée 512x512, et une autre modif du code générant ces tuiles stockées).
Ce n'est pas ridicule : rien que pour gérer jusqu'au niveau 12 les tuiles du monde entier, on monte très vite en nombre de fichiers, et cela impose une charge importange sur le système de fichiers si on stocke tout dans le même dossier cache. Répartir les fichiers sur des dossiers multiples aide beaucoup l'OS à gérer les modifications et recherches rapides dans ce dossier (on sait que NTFS devient particulièrement lent à partir du moment où on met plus de 2000 fichiers dans un même dossier, mais on a aussi le même problème avec FAT pour les recherches où c'est le temps d'accès qui devient de plus en plus long, avec une charge supplémentaire sur la taille du cache en mémoire, sans compter aussi des problème de verrous exclusifs lors des modifs par des processus ou threads concurrents). Je n'ai aucune idée de la façon dont vous organisez le stockage sur votre serveur, en terme d'organisation des fichiers. D'une façon générale les système de cache de stockage cherchent à diviser les fichiers en de nombreuses sous-collections (thème déjà abordé concernant le cache JTiles intégré à JOSM qui souffre sévèrement de ce problème de manque d'organisation et qui impose une charge trop importante à l'OS hôte). Ces solutions se retrouvent dans tout bon navigateur Internet (même l'installation la plus simple d'IE crée un cache divisé en au moins 4 ou 5 sous-dossiers avec une distribution pseudo-aléatoire des contenus entre les sous-dossiers ; on a la même solution dans le cache de déploiement Java, et dans les caches des autres navigateurs comme Firefox, Chrome, Opera, ou dans les caches de proxy frontaux comme Squid... Ca demande un peu de tuning si on veut maintenir des collections importantes de fichiers). Le 11 février 2013 04:53, Philippe Verdy <verd...@wanadoo.fr> a écrit : > Le 10 février 2013 13:44, Christophe Merlet <red...@redfoxcenter.org> a écrit > : >> A part le fait que tu es complètement hors sujet dans ce fil de >> discussion, je suppose que tu t'es monté ton propre serveur de tuiles >> pour tester. >> Tu peux nous dire les perfs que tu obtiens pour comparer ? > > Usage purement local et certainement pas comparable en matière de > matériel. Je n'ai tout bonnement pas besoin des mêmes performances, le > nombre de requêtes à traiter est ridicule en comparaison. > Au delà de ça, vous devez savoir comment optimiser le stockage sur vos > serveurs, il n'y a de toute façon pas d'urgence de changer quelque > chose au vu des ressources utilisées. > Mais puisque vous avez donné ces stats pour répondre à la demande de > quelqu'un pour lui suggérer de monter un serveur de tuiles, ces stats > ne sont utiles que pour montrer les ressources réellement nécessaires. > Bref ma réponse restait bien DANS le sujet. Si ce n'est pas le cas, > alors même la réponse donnée avant moi au sujet de ces statistiques > est également hors sujet. _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
