[OSM-talk-fr] Tuiles provenant de .org lentes (ou pas ?)

[Christian Quest]

Dans les 5 serveurs mis à disposition d'OSM FR par OVH, nous avons passé
les clés d'un des deux "gros" (EG-128) à la fondation pour du rendu de
tuiles. C'est scortch si ma mémoire est bonne.

La saturation provient de la combinaison de plusieurs facteurs:
- augmentation du nombre de requêtes
- densité de données de plus en plus élevée et donc un rendu plus long...
il suffit de consulter la version 2010 d'archeosm pour voir que le rendu
est rapide (et sans SSD)

Comme ni l'un ni l'autre de ces facteurs ne risque de s'inverser, il faudra
sûrement changer de stratégie.

Pour le problème de multi-rendu décrit par Marc, j'avais imaginé des
serveurs dédiés à une partie de la planète, en se basant sur de grands
ranges de numéros de tuiles.
Ce sont les proxy/cache qui devraient s'occuper de router vers un serveur
dédié à la zone demandée.
Quelques règles dans une config nginx pourraient gérer ça, y compris la
redondance (2 serveurs pourraient assurer le rendu d'une zone et tous
pourraient conserver une base "monde" comme actuellement pour permettre
tout changement dynamique).

Peut être un sujet à discuter autour de houblon liquéfié en fin de
semaine...


Le lun. 16 sept. 2019 à 22:27, marc marc <marc_marc_irc at hotmail.com> a
écrit :

> Le 16.09.19 à 22:05, Baptiste Jonglez a écrit :
> > D'habitude c'est plutôt les serveurs de cache qui saturent, mais en ce
> > moment j'ai l'impression que scorch a aussi du mal :
>
> j'avais l'impression inverse (le cache suit mais le serveur de rendu
> est saturé depuis > 1 an la journée)
>
> > Est-ce qu'il a déjà été envisagé que l'asso OSM-FR mette des serveurs à
> > disposition ?
>
> le vrai soucis c'est l'architecture au niveau des serveur de rendu.
> si 2 utilisateurs consulte la même tuile via 2 cache-srv de rendu
> différent, la tuile est produite sur chacun des 2 serveurs de rendu.
> du coup ajouter un serveur de rendu ne diminue pas bcp la charge (la
> charge ne diminue que des tuiles qui ne sont vue que sur les caches
> lié à ce serveur là)
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Christian Quest - OpenStreetMap France
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20190917/c1578792/attachment.htm>