Bonjour, Je lurke depuis quelque temps sur le projet OSM que je trouve incroyable, et j'ai cru comprendre que les requêtes de tuiles sont un véritable problème parce qu'elles consomment un max de ressources, ressources qui ne coulent pas à flot, d'où l'importance de la gestion de caches.
Aujourd'hui, si j'ai bien compris, la gestion des caches reste au niveau de HTTP: * Soit un Squid de la fondation a la tuile demandée en cache, il va la distribuer * Soit il ne l'a pas, la tuile doit éventuellement être générée puis transférée au client Dans le deuxième cas, même si le client a une version précédente de la tuile, il va falloir télécharger la nouvelle de zéro. C'est un peu bête, surtout que les tuiles changent pas énormément entre deux itérations (surtout dans les zones déjà bien renseignées), du coup télécharger 20Ko de pixel alors qu'il y en a 3 qui change, ça me fait mal à mon côté "j'aime les belles solutions techniques". Je pensais proposer une solution à la zsync [0]. L'idée est simple : pour chaque tuile générée, on génère un fichier qui sert, en gros, à décrire les blocs qui composent ce fichier. Lorsqu'un client qui a déjà une tuile en local va demander la nouvelle version de la tuile (avec un If-None-Match et un If-Modified-Since), il va demander ce nouveau fichier, tout petit (~250 octets). Si la tuile a changé, il va comparer ce fichier et la description de sa propre tuile pour trouver les blocs qui ont changé, et demander ceux-ci au serveur de tuile; il va ensuite pouvoir reconstruire la nouvelle tuile en local, sans avoir transféré la tuile complète ! En fait, ce procédé c'est plus ou moins un rsync modifié. La différence notable c'est qu'il n'y a pas besoin d'avoir un logiciel spécial côté serveur pour _servir_ les blocs, puisque la logique se fait uniquement au moment de la génération de la tuile. Les blocs sont distribués sur simple requête HTTP via le header Range. Ça ajoute un peu de processing à côté de la génération des tuiles (je crois savoir que le serveur en charge aimerait bien se passer de toute charge supplémentaire), mais il n'est pas énorme (des tests rapides montrent une vitesse moyenne de ~100Mo/s sur mon core i5) Le monde n'est pas tout rose, et cette solution ajoute un aller-retour qui va augmenter le temps total avant affichage, mais si ça peut soulager les serveurs de la fondation c'est pour moi beaucoup plus important. J'ai tendance à souvent me lancer dans des projets jusqu'à un point où je me rends compte que le besoin n'existait pas. Du coup j'aimerais inverser la tendance et demander quelques stats d'utilisations des serveurs avant: est-ce qu'il y a beaucoup de clients qui font des GET avec des headers de cache, et on leur répond que leur tuile est trop vieille avec la nouvelle toute entière ? Ou est-ce qu'il y a très peu de requêtes avec ces headers (j'ai vu [1] qu'il y a moins de 4% de 304, ça me semble faible) ? J'ai un prototype plus ou moins fonctionnel, je serai ravi de vous le montrer si tout ça a du sens. [0] http://zsync.moria.org.uk/ Cordialement, -- Matthieu RAKOTOJAONA _______________________________________________ dev-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev-fr
