C'est vrai que le problème de facturation concerne avant tout les applications très asymétriques en bande passante.
Installer un cache Squid bien positionné dans la topologie du réseau est une solution pour réduire le déséquilibre des liens de peeering (sinon soit on paye le surplus, soit un se voit réduire drastiquement la bande passante). La Fondation Wikimedia ne diffuse pas que du contenu statique : les nombreuses pages de discussions et modifs de pages imposent que ce contenu change et n'entre plus dans les caches, même avec l'aide d'un CDN ou d'une série de serveur Squid managés par la fondation elle-même dans quelques GIX mondiaux stratégiques. Mais elle a aussi le même problème de charge sur ses moteurs de rendu MediaWiki : un cache ou un CDN ne peut pas tout résoudre, et il faut nécessairement monter aussi le nombre de serveurs de rendus et les mettre en réseau avec un système de distribution de la charge de travail (tout en veillant à ce que les serveurs de rendu puissent aussi disposer d'une bande passante suffisante et d'un bon temps de réponse pour rester synchronisés avec la base de données, la distribution de charge de travail sur la base de données elle-même étant un problème bien plus difficile (sauf si, comme actuellement, on accepte que les serveurs de rendus travaillent sur des réplications de la base avec un certain délai acceptable). Bref que l'on parle de la base de données OSM ou celle de Wikipédia, les difficultés pour monter en charge et garder la synchronisation acceptable en cas de distribution sont de même nature (la plus grosse difficulté est tout de même sur l'interface permettant de soumettre des modifications car on doit nécessairement s'appuyer sur une base maître chargée de lever les conflits et gérer le versionnement des contenus). Mais on n'est pas à la même échelle : le nombre de contributeurs actifs à Wikimédia est beaucoup plus élevé que ceux d'OSM, si on y inclut les pages de discussions, et surtout les envois massifs de photos vers Commons, qui sont eux aussi versionnés mais distribués par un système de répartition des répertoires, le goulot restant dans l'index général des fichiers et des catégories pour leur mise à jour). Heureusement les photos chargées sur Commons changent très peu, et pour ensuite les transférer vers les visiteurs les serveurs Squi ou les alliances avec les CDN ou FAI réduisent considérablement la bande passante de ces photos (mais très peu les pages de discussions et les données des profils d'utilisateurs qui nécessitent une modification des pages en cache pour y rajouter les données personnelles de profils, telles que les notifications en tête de page). Donc même pour les wikis de Wikimedia,les serveurs cache ou CDN ne sont pas suffisants pour la charge des pages HTML qui changent pour chaque visiteur et même à chaque rechargement d'une page par le même utilisateur. Le 19 décembre 2012 10:41, Christophe Merlet <red...@redfoxcenter.org> a écrit : > Le mercredi 19 décembre 2012 à 00:26 +0100, Christian Quest a écrit : > > Constat proche pour moi (aussi chez free), le ping est quasiment > > identique (dans les 40/45ms) et même nombre de hops. > > > > Un cache de tuile chez free Bezons diviserai mon ping presque par 2 > > (23ms en moyenne sur osm11) ;) > > Le geodns pourrait-il rediriger les requêtes provenant des AS de free > > vers un serveur chez free ? > > Le GeoDNS redirige les IP par pays entier. Il ne semble pas y avoir de > subdivision. > > De plus pour fournir un cache de tuiles à la fondation OSM, il y a > quelques conditions à réunir... > https://wiki.openstreetmap.org/wiki/Servers/Tile_CDN > > > Concernant les temps d'accès, c'est un problème connu. > Il y a un GIX à Pau sur lequel Axione et RENATER échangeait du trafic. > Mais cela posait un petit problème... lorsqu'une université francilienne > souhaitait accéder à un client citéFibre (à paris donc), il faisait un > aller-retour à Pau... Les joies du routage Internet ! > De plus, le routage n'est pas qu'un problème technique, c'est aussi et > surtout un problème financier. Les opérateurs de transit facture la > bande passante dans des rapports pouvant aller de 1 à 20 ! Donc il > revient facilement moins cher d'aller faire son peering sur un GROS GIX > fédérateur, voire à l'étranger que sur un nœud local. > > Des discussions d'il y a quelques années faisant un état des lieux... > http://lafibre.info/paubc/index.php/topic,1704.0.html > > > Pour ceux qui l'ignore, Pau est la première ville^Wagglo de France a > avoir déployé son propre réseau FTTH. Il dessert plusieurs dizaines de > milliers d'habitants > https://fr.wikipedia.org/wiki/Pau_Broadband_Country > > Aujourd'hui, le plus grand FAI a destination du grand public utilisant > ce réseau est SFR. Il a été rejoint cette année par Orange > > http://www.larepubliquedespyrenees.fr/2012/04/19/fibre-optique-premieres-offres-d-orange-avant-noel,232898.php > On peut donc espérer qu'avec 4 gros opérateurs nationaux (RENATER, > Axione, SFR, Orange) ils voient un intérêt financier à peerer proprement > en local... > > > > Christophe, ça serait possible de rajouter ce serveur dans le munin > d'OSM-FR ? > > On a déjà notre propre munin > http://tile.paulla.asso.fr/munin-osm/ > > La fondation OSM intégrera ce serveur dans son propre munin > http://munin.openstreetmap.org en janvier. (Il faut qu'on lui ouvre des > ports supplémentaires pour ce faire) > > > Librement, > -- > Christophe Merlet (RedFox) > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr