(Je bascule sur dev-fr, talk-fr est déjà très largement sur-chargée, et ce fil de discussion me semble assez technique)
Le vendredi 04 janvier 2013 15:41:59, Cyrille Giquello a écrit : > Le 4 janvier 2013 15:33, Christian Quest <[email protected]> a écrit : > > Je ne sais pas si c'est cette requête pour maintenir les area à jour > > qui est lourde où si ce sont celles les utilisant ensuite sur > > l'overpass... > > C'est surtout leur génération qui est lourde, me semble-t-il. C'est en effet leur génération qui est lourde, je n'ai pas encore regardé en détail comment ça fonctionne, mais ça fout un CPU à 100% en permanence et ça bouffe du disque. Alors que personne ne savait que j'avais glissé en test les calculs des areas sur oapi-fr.openstreetmap.fr la machine perdait terriblement en rapidité pour les autres requêtes. Roland ma conseillé de lui attribué une priorité plus faible (nice) mais ça ne résout que le problème CPU, pas le problème i/o Je vais faire des tests avec ionice, mais le coeur du problème restant bien évidement que ça ne devrait pas bouffer à ce point. > > C'est vrai aussi qu'à un moment passer à postgis offre un autre champ > > de possibilités, il faudrait ajouter un moyen de requêter postgis via > > HTTP pour une exploitation dans les slippymaps. Tiens, ça me rappel un conseil que j'ai donné récemment sur [tech] ;-) > Ça risque d'être encore plus chaud : très facile de saturer le serveur > puisque l'on pourrait tout lui demander tout le temps. Oui mais ça ressemble au même problème avec l'overpass. Si on veut le faire, à nous de trouver une méthode permettant de terminer les requêtes trop longues et d'avoir une règle d'utilisation et des restrictions. > L'overpass-API c'est super bien: > - un type de requêtes largement suffisant oui > - une construction des données optimisées pour le type de requête Oui, sauf les areas ;-) > - un service qui tient la route Oui bon ça, ça se discute ;-) mais les choses s'améliorent > L'option de limite des requête sur un polygone est vraiment super, > même si limitée à un type de données. Et en plus ce filtrage est > négociable ;-) Ou alors, mais ça devient délicat, se goupiller un couplage postGIS(osm2pgsql)/overpass(ou osmbin) pour obtenir le meilleur des deux mondes. Mais c'est de loin plus facile à dire qu'a faire. -- sly (sylvain letuffe) _______________________________________________ dev-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev-fr
