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

[Matthieu Rakotojaona]

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