Le 17 février 2012 10:35, Ab_fab <gamma....@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). _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
