Re: [OSM-dev-fr] Proposition d'amélioration de la gestion du cache
Bonjour Matthieu, Ne transmettre qu'un diff de ce qui a changé sur une tuile impliquerai de conserver côté serveur, la dernière version d'une tuile ainsi qu'un certain nombre de diff des versions précédents. Ce mécanisme ne fonctionnerai correctement que si le client a déjà une ancienne tuile dans son cache. Est-ce si souvent le cas ? Je pense surtout que le problème de ressources n'est pas dans le transfert des tuiles, mais plus dans leur génération. L'avenir se situe sûrement dans un domaine tout autre: les tuiles vectorielles... et le rendu au niveau du client. Le 5 mai 2013 12:07, Matthieu Rakotojaona matthieu.rakotoja...@gmail.com a écrit : 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 dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Proposition d'amélioration de la gestion du cache
Là aussi on peut penser à une autre piste: l'adaptation de la taille des tuiles servies en fonction de la densité: rien n'oblige les métatuiles à avoir la même taille, et le protocole pourrait mentionner la taille des métatuiles touchées, pour réduire le nombre de requête ou optimiser les requêtes en terme de compression et d'échanges : quand une tuile est retournée, une métadonnée peut indiquer quelles autres tuiles font partie de la même métatuile générée, et retourner alors non pas la tuiles mais l'indication d'une autre tuile plus grande ou de plusieurs autres plus petites. Mais le protocole WMS ne semble pas avoir prévu ce type d'adaptation (dynamique en fonction des contenus). Le protocole cependant supporte de remplacer une tuile par une autre (fonctionalité offerte par HTTP via des redirections : cela permettrait par exemple de retourner la même tuile une seule fois quand elles sont identifiques entre elles pour des zones assez grandes : une signature MD5 ou SHA1 des données de la tuile générée suffirait à identifier les tuiles identiques dans leur contenu (mais pas forcément dans leurs métadonnées de géolocalisation notamment). Au pire cela gagnerait de l'espace de stockage côté serveur (il créait des liens symboliques ou physiques en stockant ses tuiles sous un nom issu de la signature de contenu), mais pas de temps pour générer ces tuiles (générer une signature SHA1 est aujourd'hui une opération très rapide, avec des accélérations matérielles dans les processeurs ou des optimisation importantes, disponibles dans les bibliothèques de sécurisation, on obtient facilement aujourd'hui le gigaoctet par seconde pour SHA1, dont le calcul aurait alors un temps négligeable en comparaison du temps gagné sur les accès disques épargnés par le stockage partagé des tuiles identiques). Pour le reste, la vraie charge côté serveur c'est le temps de génération de ces tuiles et la complexité des requêtes SQL à effectuer, et des traitements géométriques, plus le traitement graphique plus ou moins complexe pour le rendu lui-même, et enfin les I/O pour stocker les tuiles générées. La piste d'optimisation c'est alors de voir si les métatuiles ne sont pas trop grandes par rapport à la demande réelle, et savoir gérer côté serveur des métadonnées sur leur fraicheur et leur fréquence de mise à jour (ou durée minimale avant l'obsolescence). Coté serveur on n'est pas non plus obligé de faire patienter le client même si on a marqué une métatuile comme obsolète: on peut lui servir immédiatement une tuile qu'on sait obsolète, mais qui sera mise à jour plus tard : si on le fait on ne change rien aux métadonnées retournées au client et on peut lui indiquer une date de péremption actualisée légèrement dans le futur (jusqu'à une date estimée où cette tuile aura bien été régénérée du côté du serveur). Le serveur peut estimer cette date du futur en pistant le délai entre les dernières mises en file d'attente de tuiles à régénérer et le moment où elles sortent de cette file d'attente. Dernière problème : les tuiles demandées et que le serveur ne stocke pas (cela concerne les niveaux de zoom élevés) : là seul un proxy Squid frontal permet d'éviter de surcharger le serveur de génération des tuiles, mais il vaut mieux que pour ces tuiles il y ait un serveur de génération séparé de clui des tuiles que le serveur veut stocker et garder à jour (pour les niveaux de zoom faibles) : - on touche alors au tuning des serveurs Squid (programmation des durées minimales de conservation en cache), et - on doit se demander aussi comment les clients gèrent eux-mêmes leurs propres caches HTTP (les navigateurs web font ça très bien, mais pas les éditeurs hors navigateurs, comme JOSM). Cependant même pour les navigateurs Web, on est lié aussi à la façon dont les frameworks javascripts exécutent leurs requêtes HTTP : ces requêtes sont-elles correctement cachables du côté client et du côté serveur pour que jamais l'utilisateur n'ait à s'occuper de vider son cache local ? Le 6 mai 2013 08:20, Christian Quest cqu...@openstreetmap.fr a écrit : Bonjour Matthieu, Ne transmettre qu'un diff de ce qui a changé sur une tuile impliquerai de conserver côté serveur, la dernière version d'une tuile ainsi qu'un certain nombre de diff des versions précédents. Ce mécanisme ne fonctionnerai correctement que si le client a déjà une ancienne tuile dans son cache. Est-ce si souvent le cas ? Je pense surtout que le problème de ressources n'est pas dans le transfert des tuiles, mais plus dans leur génération. L'avenir se situe sûrement dans un domaine tout autre: les tuiles vectorielles... et le rendu au niveau du client. Le 5 mai 2013 12:07, Matthieu Rakotojaona matthieu.rakotoja...@gmail.com a écrit : 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
Re: [OSM-dev-fr] Proposition d'amélioration de la gestion du cache
Le 06/05/2013 14:09, Philippe Verdy a écrit : Là aussi on peut penser à une autre piste: JUST DO IT Librement, -- Christophe Merlet (RedFox) ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Proposition d'amélioration de la gestion du cache
2013/5/6 Christian Quest cqu...@openstreetmap.fr: Bonjour Matthieu, Ne transmettre qu'un diff de ce qui a changé sur une tuile impliquerai de conserver côté serveur, la dernière version d'une tuile ainsi qu'un certain nombre de diff des versions précédents. Justement non : le serveur conserverait la dernière tuile uniquement, comme aujourd'hui, ainsi que le fichier signature associe permettant de calculer le diff (la encore le dernier suffit). Ce serait au client de calculer le diff via ce fichier signature entre la version qu'il a en ce moment (ca peut même ne pas être la dernière) et la nouvelle du serveur, puis de demander les blobs qui ont changé. Pour cette dernière étape, un GET avec les bons header Range: suffit (c'est déjà supporte aujourd'hui, rien a changer) Ce mécanisme ne fonctionnerai correctement que si le client a déjà une ancienne tuile dans son cache. Est-ce si souvent le cas ? Justement, c’était ma question, vu que je n'ai pas accès aux logs. Je sais pas si c'est facilement accessible dans les logs tels quels; s'il faut parser, est-il possible d'avoir quelques lignes pour tester ? Je pense surtout que le problème de ressources n'est pas dans le transfert des tuiles, mais plus dans leur génération. Ca je veux bien le croire. L'avenir se situe sûrement dans un domaine tout autre: les tuiles vectorielles... et le rendu au niveau du client. Il va falloir que je me documente sur le sujet, je ne savais pas que ca existait. Merci ! -- Matthieu RAKOTOJAONA ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Proposition d'amélioration de la gestion du cache
Bonsoir, Le 6 mai 2013 16:17, Matthieu Rakotojaona matthieu.rakotoja...@gmail.coma écrit : 2013/5/6 Christian Quest cqu...@openstreetmap.fr: L'avenir se situe sûrement dans un domaine tout autre: les tuiles vectorielles... et le rendu au niveau du client. Il va falloir que je me documente sur le sujet, je ne savais pas que ca existait. Merci ! Voir par exemple ici (c'est tout chaud) http://mapbox.com/blog/vector-tiles-tilemill2-preview/ -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus, Nadja ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
