[OSM-talk-fr] [ANNONCE] Blog de MapOSMatic

Emilie Laffray emilie.laffray at gmail.com
Mar 29 Sep 15:09:40 UTC 2009


2009/9/29 sly (sylvain letuffe) <sylvain at letuffe.org>

> Je serais très curieux de voir des benchs comparatifs entre une solution
> "plus
> de RAM" et une solution "plus de disques" (histoire de savoir où
> investir :-) )
>

Je ne peux pas vraiment fournir de benchs car on ne fait que de la lecture
seule. Le load test tool que j'ai écrit il y a quelques temps montre que je
n'arrive pas a maxer les serveurs postgresql a partir de ma machine :) Au
final, ce que l'on voit, ce sont les temps de latence provenant du serveur.
Il faut que je prenne le temps un jour de faire un beau test Jmeter afin de
bien mettre en valeur l'augmentation de performances que l'on a eus. Il n'y
a qu'un import tous les 2 mois. L'import et toutes les étapes prennent
environ une semaine du fait du preprocess.


> Mais aussi, selon la taille du fichier osm. Je me doute bien que si toute
> la
> base postgis tient en RAM ça doit dépoter sévère.
>
>
Oui mais pas forcement, ça dépend aussi de la géométrie que tu utilises et
la manière dont tu utilises tes fonctions. Disons qu'une géométrie
LINESTRING se cache très bien et pour l'utilisation que j'en fais c'est
absolument génial. Les polygones sont aussi très efficaces a cacher surtout
si tu as beaucoup de mémoire.
Par contre, le problème et le point noir ce sont les points. C'est de loin
le plus lent sur les requêtes que je fais (un ordre de magnitude plus lent).
Je travaille sur le monde entier. Il y a bien sur des moyens de biaiser pour
augmenter les performances selon ce que tu recherches. Les partitions tables
sont une de ces solutions.



> > Question bête: lisez vous les fichiers directement en bz2 ou ont ils été
> > décompressés?
>
> Moi bz2 toujours, c'est plus simple et... sisi, plus rapide ;-)
> Mon serveur a du cpu à revendre durant les imports, par contre, pas les
> io...
>

En effet, c'est mieux d'utiliser bz2. C'est beaucoup plus rapide et ça
réduit sérieusement les IO. En moyenne, le ratio de compression est
d'environ 20.

Emilie Laffray
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20090929/f0617177/attachment.htm>


Plus d'informations sur la liste de diffusion Talk-fr