[OSM-dev-fr] Proposition d'amélioration de la gestion du cache

[Christian Quest]

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.rakotojaona at 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 at 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