[OSM-talk-fr] mongeosource utilise OSM

Philippe Verdy verdy_p at wanadoo.fr
Sam 18 Fév 14:03:05 UTC 2012


Le 17 février 2012 10:35, Ab_fab <gamma.gts at gmail.com> a écrit :
> Bon, peut être qu'il n'y a pas à s'affoler :
> Le BRGM est un service important, mais peut être pas au point de saturer le
> système.
> Combien de personnes vont effectivement consulter ce site jour après jour,
> et durant combien de temps ?
>
> Pour moi, ce qui peut poser problème, ce sont les sites très communs,
> consultés par le grand public.
> (RATP, la FNAC et la SNCF ...).
>
> Les services qui font "vraiment mal" aux serveurs de tuiles sont ceux qui
> proposent le téléchargement de toutes les tuiles d'un secteur, jusqu'au zoom
> le plus élevé (z18), pour une consultation ultérieure hors-ligne.
>
> Les utilisateurs "humains" sont moins néfastes car ils ne balaient que des
> zones limitées à ces zooms élevés, et souvent aux mêmes endroits (zones
> urbaines)
>
> L'image suivante montre la répartition des tuiles générées par un serveur :
> on voit que plein de zones (noires) sont en fait vierges de tuiles pour les
> zooms élevés.
> http://wiki.openstreetmap.org/wiki/File:Example-image-available-tiles-on-tileserver.png
>
> Tant que le site du BRGM ne propose qu'une balade avec une carte glissante,
> je dirais que le mieux est la confiance à priori, à condition qu'il soit
> possible de jauger côté osm.org la charge engendrée par tel ou tel service
> consommateur afin d'identifier les abus.
>
> D'ailleurs, je crois que c'est la pratique en cours :
> http://wiki.openstreetmap.org/wiki/Tile_usage_policy
>
> Monter un serveur de tuiles n'est pas encore aussi simple que monter un
> service web "classique", donc je n'irais pas jusqu'à les traiter de
> fainéants.
> Je leur conseillerais plutôt d'utiliser les tuiles Mapquest

Sans aller jusqu'à monter un serveur de tuiles, monter un serveur
proxy cache pour leur propre usage sur leur site n'est pas d'une
complexité alarmante. Et cela leur bénéficiera en donnant plus de
réactivité à leur site, tout en soulangeant la charge des serveurs de
tuile communs.

Bref on peut militer pour la mise en place de ces proxy cache comme
Squid, et la politique évoquée ici:

http://wiki.openstreetmap.org/wiki/Tile_usage_policy

devrait suggérer cette possibilité (à condition toutefois que ce proxy
cache respecte lui-même cette politique, en montrant clairement que
l'usage du serveur de tuile constitue une économie réelle de
ressources sur le serveur de tuile, en comparaison des accès effectués
par les clients au proxy cache.

En cas de surcharge d'un serveur de tuiles par des requêtes nombreuses
venant du proxy cache, on peut mettre en place un dispositif d'alerte
demandant à ce que le serveur cache publie des statistiques et
démontre qu'il est accessible pour des services accessibles au public
auquel il soulage les accès. et à un certain niveau d'utilisation, on
peut alors chercher des solution permettant une
réplication/propagation plus intelligente des données vers les caches,
quitte à leut imposer un intervalle de préservation plus long des
données dans leur cache (par exemple su un serveur de tuile mentionne
une durée de validité/conservation en cache de 24 heures, on pourrait
suggérer à ceux qui maintiennent un cache d'augmenter cette durée, au
moins pour certains niveaux de zoom peu élevés sur lequel les tuiles
sont plus fréquemment mises à jour).

Le principe est exactement le même dans le cas des systèmes DNS qui
ont un modèle de distribution par caches successifs, et où on demande
aux services DNS intermédiaires d'optimiser les durées de
conservation. Sans ce système, c'est le système mondial du DNS qui
aurait explosé complètement, il n'aurait jamais tenu la charge.

Ensuite on peut chercher à développer les serveurs de tuile
supplémentaires (mais là encore, se posera la question de la charge
des accès par ces serveurs à la base OSM principale, qui elle aussi
devra avoir un système de propagation/réplication avec des caches et
mises à jours planifiées).




Plus d'informations sur la liste de diffusion Talk-fr