On peut voir que le réseau Mondial Relay consomme à lui tout seul pas mal de bande passante pour localiser ses points de livraison colis via les sites marchands. Idem pour rail.cc.
Il faudrait peut-être voir à les informer qu'on ne peut pas assurer la qualité de bande passante et de temps de réponse, et qu'ils devraient utiliser leur propre proxy cache sur pour leur réseau s'ils ne veulent pas monter leur serveur de tuiles. Ca leur coûterait tellement cher de mettre un ou deux serveurs Squid pour leur service je ne sais pas si au passage ils ne participent pas au financement à hauteur du service qu'ils en attendent, ce qui serait aussi une alternative pour permettre de monter plus de redondance et de qualité de service pour tous) ? Je ne sais pas si on peut limiter l'usage par "referer" à une limite raisonnable. Mais là je pense que les deux sites font trop confiance à cette ressources gratuite. S'ils ne veulent pas payer d'abonnement chez Google ou MapBox, un serveur Squid est tout de même le minimum qu'on peut leur demander (et qui leur assurera aussi un bon temps de réponse, surtout que leur réseau ne couvre pas tant de territoire que ça, et qu'ils n'ont pas forcément besoin de zoomer sur toute la planète mais uniquement sur les points de livraison (ils peuvent désactiver le zoom/panning dynamique et mettre quelques tuiles basse résolution et des tuiles uniquement dans les zones couvertes et permettant de distinguer les points de livraison très locaux). Pour rail.cc, comme ils demandent à faire des itinéraires, ce sont en général des grandes distances et les niveaux de zoom élevés ne sont pas forcément essentiels. Mais dans les deux cas un proxy cache transparent soulagerait notre service même si au passage ils participent au financement (matériels à ajouter, maintenance, frais d'exploitation divers: domaines, certificats, frais de location et d'accès aux espaces de colocations, factures d'énergie, sécurité, frais administratifs, participation aux frais de communication, frais de campagne et de promotion, frais de déplacements...). Le 19 novembre 2017 à 21:25, Christian Quest <cqu...@openstreetmap.fr> a écrit : > J'ai généré des statistiques sur l'usage de 2 serveurs de tuiles maintenus > par OSM-France depuis le mois de janvier. > > Il s'agit d'osm13 et osm25 qui s'occupent principalement des tuiles HOT et > FR. > > Ces stats sont celles du cache de tuiles, qui est hébergé à Lyon par > Rezopole pour OSM-France (ne pas confondre avec le cache de tuiles pour > osm.org hébergé aussi par Rezopole à Lyon). L'avantage de Rezopole est > que ce cache est situé physiquement sur un noeud d'interconnexion, ce qui > réduit les temps d'accès depuis de nombreux opérateurs et fait aussi que la > bande passante a un coût nul. > > Donc depuis janvier, ce cache a distribué plus de 2,5 milliards de tuiles, > ce qui représente plus de 38To de données utiles. > Record le 6 octobre dernier avec 23.8M de tuiles dans la journée ! > > Les tuiles les plus demandées sont celle du zoom 15 HOT, puis du zoom 18 > FR. > > uMap génère 17% des demandes, puis 10.7% pour osm.org (qui permet > d'afficher le rendu HOT). > > > Le détail est sur http://osm13.openstreetmap.fr/~cquest/report.html > > Je vais ajouter une mise à jour si possible quotidienne... et oui, il > manque quelques jours de stats (disque plein car les logs sont > volumineux... mais maintenant c'est réglé). > > -- > Christian Quest - OpenStreetMap France > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
