En gros tu proposes un proxy plus intelligent que Squid (qui ne différencie pas les zones à afficher ni la géolocalisation des clients).
Je pense que la différenciation des zones à afficher sur des serveurs dédiés serait utile à l'échelle continentale au mieux, mais qu'ici le but est de réduire les coûts en bande passante et donc d'utiliser en priorité la géolocalisation des clients. Et pour ce dernier objectif (géolocalisation des clients, ou plutôt détermination de la route IP par laquelle ils arrivent), il vaut mieux s'appuyer sur un serveur DNS dynamique (qui retournera l'adresse du bon serveur à utiliser selon la géolocalisation du client, en retournant un nom de domaine alternatif par une entrée "CNAME"). Ce sera beaucoup plus efficace qu'un proxy "intelligent" qui aura son lien amont (accès par les clients) surchargé et pas réparti en bande passante, même si son lien aval (du côté des serveurs de rendu) il va faire faire des économies aux serveurs de rendu : là on gagnera réellement de la bande passante au niveau des routeurs d'entrée (et notamment sur les liaisons de peering, entre lesquelles on pourra gérer la répartition des bandes passantes). Ensuite ce qu'on met au bout des adresses redirigées par le proxy peut être un gros serveur de rendu avec un petit cache Squid frontal, ou un petit serveur de rendu et un gros cache Squid frontal (mais dans les deux cas une date de péremption bien plus rapide, pour les réponses HTTP émises du serveur de rendu vers Squid, puisque entre les deux, le frontal Squid et le(s) serveurs de tuiles et de rendus cela peut se faire sur une boucle locale à coût voisin de zéro en terme de bande passante utilisée). Le 19 décembre 2012 19:56, sly (sylvain letuffe) <[email protected]> a écrit : > On mercredi 19 décembre 2012, Jocelyn Jaubert wrote: > > Je me demandais: est-ce que avoir un serveur de rendu dédié à une région > > spéciale (genre la France) serait une solution envisageable ? > > Jocelyn, tu penses à tout ;-) > > Je pense que ça peut se creuser, y'a de l'idée et j'ai même commencé à > mettre > sur papier quelques idées, mais j'ai peur que ça soit un peu délicat et pas > super robuste (en tout cas avec mes bidouilles à deux balles que j'ai en > tête), il faut que je chercher voir si squid, ou apache peut nous faire ça > en > mode proxy. > > De prim abord, je pense que la puissance nécessaire à faire un rendu sur la > terre, bien que pas vraiment possible avec mon smartphone, n'est pas non > plus > impossible. Je prouverais (dès que cquest c'est occupé de ma VM au lieu de > jouer avec des kernels :-p ) , que c'est possible avec les serveurs que la > fondation free a eu le bon goût de nous fournir. > (j'ai peur de découvrir toutefois qu'un SSD aurait vraiment été bien, > auquel > cas je ferais mon malin à dire "J'l'avais dis" :-p) > > Et cette croyance actuelle que j'ai m'incite à ne pas m'éparpiller à coller > des bouts des ficelles entre eux mais partir sur une "vrai" solution, avec > une babasse qui dépotte > > > En gros, l'idée serait d'avoir un serveur de rendu par région, qui ne > > contiendrait qu'un petit terrain, et sur les zoom élevés. Ça devrait > > permettre > > de diminuer grandement la taille de la machine nécessaire, en la mettant > là > > où > > c'est le plus nécessaire. Avec les diffs locaux, ça pourrait être > possible. > > Oui, je le crois tout à fait réaliste en terme de puissance, moins en > terme de > réalisation. > Pour info, je continue à faire un rendu europe à jour real time avec des > vieux > style mal optimisés sur un 4-coeur + 8GO de RAM sans SSD, donc oui, j'y > crois > et ce, en grande partie grâce à ce que tu as développé pour les europe > diffs) > > En quoi j'ai peur de la réalisation ? > le protocole utilisé est TMS, on l'appel comme ça : > http://duchmol/zoom/x/y.png > > Et, hélas pas, ainsi : http://zone-[bbox max].duchmol/zoom/x/y.png > Ou il aurait été bien plus facile de préparer un cluster géographique > réparti > ou chaque serveur annonce quelle bbox il peut couvrir et le client > openlayers > supportant ce faux TMS se charge d'interroger le bon serveur de la bonne > zone > > En clair avec le vrai TMS, on tombe sur un seul serveur, et lui ne sait pas > encore s'il peut ou non servir la requête, l'idée que j'ai est donc un > proxy > (non cache) intelligent que je préfère nommer "le dispatcher" > > Son rôle et de transmettre la demande au bon serveur qui gère la bonne > zone, > il doit : > - maintenir une liste des serveurs ordonnés de zone et la zone qu'ils > couvrent > - faire le calcul, à partir d'une URL TMS afin de déterminer dans quelle > zone > elle se trouve > - Proxier/ou rediriger par un HTTP 301 la demande de l'internaute vers le > serveur le plus adapté > > Bigre, rien qu'a l'écrire, je me dis que ça n'est pas si compliqué que ça > et > que ça pourrait largement trop bien le faire. > (cadeaux bonux, mise en cache des zoom 0 à 9 les plus souvent demandés) > > > -- > sly, DWG member since 11/2012 > Coordinateur du groupe [ga] > http://wiki.openstreetmap.org/wiki/User:Sletuffe > > _______________________________________________ > dev-fr mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/dev-fr >
_______________________________________________ dev-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev-fr
