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

Lun 6 Mai 12:09:37 UTC 2013

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 <cquest at 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.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
>
> _______________________________________________
> dev-fr mailing list
> dev-fr at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/dev-fr
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/dev-fr/attachments/20130506/026410ad/attachment.html>