Re: [OSM-talk-fr] [Technic] Serveurs

2009-06-21 Par sujet sylvain letuffe
Le samedi 20 juin 2009 17:37, Yann Coupin a écrit :
 Bon j'avais commencé à jouer avec mapnik et du coup j'ai voulu tester
 la création d'une table spécifique pour une surcouche, ça aide pas mal
 en fait, dans ton cas ça risque d'être encore plus intéressant. Voilà
 mon code SQL:

Avec un mix de ton exemple, de la doc, et l'aide de François, j'arrive à faire 
marcher le tout. Le rajout lors des minutes diff est négligeable par contre 
le résultat sur du temps réél ne l'est pas !

(En utilisant les géométries pré-simplifiées)
$ time ./nik2img.py -m communes.xml -i png -o c1.png -s 
1000,1000 -e -5,41,9,51.5

real0m7.226s

(sans)
time ./nik2img.py -m communes2.xml -i png -o c2.png -s 
1000,1000 -e -5,41,9,51.5

real1m49.012s

On divise par 15 le temps de calcul pour la france entière, et ça se confirme, 
c'est en gros le rapport qui existe entre les tailles de données à lire. Le 
rendu temps réél avec postgres c'est pour beaucoup un problème d'IO

PS a titre d'archives :

ALTER TABLE planet_osm_polygon drop column simplified_way;
ALTER TABLE planet_osm_polygon add column simplified_way GEOMETRY;


-- Add an index to the simplified column
CREATE INDEX planet_osm_polygon_simplified_way ON planet_osm_polygon USING 
gist (simplified_way);

CREATE OR REPLACE FUNCTION simplify() RETURNS trigger
AS $simplify$
BEGIN
IF NEW.boundary = 'administrative' THEN
UPDATE planet_osm_polygon SET simplified_way=st_simplify(way,200) WHERE 
osm_id = NEW.osm_id;

RAISE NOTICE 'mise a jour';
RETURN NEW;
END IF;
RAISE NOTICE 'rien';
RETURN NEW;
END;
$simplify$ LANGUAGE plpgsql;

DROP TRIGGER simplify ON planet_osm_polygon;
CREATE TRIGGER simplify AFTER INSERT ON planet_osm_polygon
 FOR EACH ROW EXECUTE PROCEDURE simplify();

/*
On notera que le trigger n'est activé que lors des inserts et pas des updates 
(ce que osm2pgsql ne fait de toute façon pas) car sinon, on part dans une 
boucle infinie car la fonction fait elle-même un update qui déclenche le 
trigger
*/

--
sly

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] [Technic] Serveurs

2009-06-21 Par sujet sylvain letuffe
 Yann :
  Après, je ne sais pas si les trigger
  vont survivre à un import complet d'osm2pgsql lorsqu'il va recréer les
  tables from scratch.
Je confirme que non, car osm2pgsql fait un drop de totu le  bazar, mais :

 Émilie :
 C'est pour ça que tu crées toujours un backup de tes scripts de création
 afin de les réimporter facilement :)

Il suffit de bien garder la création du trigger et de la fonction pour le 
faire juste après l'ami osm2pgsql
--
sly

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] [Technic] Serveurs

2009-06-21 Par sujet Etienne Chové
Pierre Mauduit a écrit :
 http://charlie.beneth.fr/mapnik (dispo en ipv6)

C'est du temps réel ? Si oui, c'est hyper fluide ça me rappele beta 
avant que tout le monde le sature.

-- 
Etienne


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] [Technic] Serveurs

2009-06-21 Par sujet sylvain letuffe
Le dimanche 21 juin 2009 16:25, Etienne Chové a écrit :
 Pierre Mauduit a écrit :
  http://charlie.beneth.fr/mapnik (dispo en ipv6)

 C'est du temps réel ? Si oui, c'est hyper fluide ça me rappele beta
 avant que tout le monde le sature.

snif, quand y'a un truc trop cool à voir ça ne marche pas de chez moi.

Quand tu dis dispo en ipv6, ça veut dire uniquement en ipv6 ?

$ telnet charlie.beneth.fr 80
Trying 82.234.24.152...
telnet: connect to address 82.234.24.152: Connection timed out
Trying 2a01:e35:2ea1:8980:224:1dff:fe24:fc02...
telnet: connect to address 2a01:e35:2ea1:8980:224:1dff:fe24:fc02: Network is 
unreachable

--
sly

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] [Technic] Serveurs

2009-06-21 Par sujet Vincent MEURISSE
 Quand tu dis dispo en ipv6, ça veut dire uniquement en ipv6 ?
Apparement oui :)

#apt-get install miredo

Pour les geeks pas sous linux :
http://en.wikipedia.org/wiki/Teredo_tunneling#Implementations
-- 
Vincent MEURISSE

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] [Technic] Serveurs

2009-06-21 Par sujet Yann Coupin
Et ça ne marcherait pas mieux de mettre un trigger BEFORE INSERT et  
au lieu de faire un UPDATE de modifier le NEW recordset ?

(pas testé, juste modifié ci-dessous, donc ça peut foirer)


Le 21 juin 09 à 15:17, sylvain letuffe a écrit :

 CREATE OR REPLACE FUNCTION simplify() RETURNS trigger
 AS $simplify$
 BEGIN
 IF NEW.boundary = 'administrative' THEN
 NEW.simplified_way=st_simplify(NEW.way,200);

 RAISE NOTICE 'mise a jour';
 RETURN NEW;
 END IF;
 RAISE NOTICE 'rien';
 RETURN NEW;
 END;
 $simplify$ LANGUAGE plpgsql;

 DROP TRIGGER simplify ON planet_osm_polygon;
 CREATE TRIGGER simplify BEFORE INSERT ON planet_osm_polygon
 FOR EACH ROW EXECUTE PROCEDURE simplify();


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] [Technic] Serveurs

2009-06-21 Par sujet sylvain letuffe
Le dimanche 21 juin 2009 18:49, Yann Coupin a écrit :
 Et ça ne marcherait pas mieux de mettre un trigger BEFORE INSERT et
 au lieu de faire un UPDATE de modifier le NEW recordset ?

Ho pinaise ! C'est exactement cette syntaxe que m'avais donné françois en 
privé que j'avais pas été foutu de recopier correctement, j'avais fais un peu 
trop de mixe entre vos deux versions pour me retrouver à oublier le 
BEFORE INSERT qui faisait qu'en gros ça ne faisait rien.

Aller va, y'a trois bout de cycle CPU à gagner mais au moins ce sera propre.



 (pas testé, juste modifié ci-dessous, donc ça peut foirer)

 Le 21 juin 09 à 15:17, sylvain letuffe a écrit :
  CREATE OR REPLACE FUNCTION simplify() RETURNS trigger
  AS $simplify$
  BEGIN
  IF NEW.boundary = 'administrative' THEN
  NEW.simplified_way=st_simplify(NEW.way,200);
 
  RAISE NOTICE 'mise a jour';
  RETURN NEW;
  END IF;
  RAISE NOTICE 'rien';
  RETURN NEW;
  END;
  $simplify$ LANGUAGE plpgsql;
 
  DROP TRIGGER simplify ON planet_osm_polygon;
  CREATE TRIGGER simplify BEFORE INSERT ON planet_osm_polygon
  FOR EACH ROW EXECUTE PROCEDURE simplify();

 ___
 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


Re: [OSM-talk-fr] [Technic] Serveurs

2009-06-21 Par sujet Pierre Mauduit
Salut,
  C'est du temps réel ? Si oui, c'est hyper fluide ça me rappele beta
  avant que tout le monde le sature.
 

Alors, par défaut, ca tombe quand meme sur le rendu officiel (désolé,
pas de miracle). Toutefois en sélectionnant le rendu real time
mapnik (petit '+' bleu sur le coté), c'est bien généré en local, et
c'est bien plus rapide que sur le dédié kimsufi de chez ovh que j'avais
expérimenté.


Une des choses qui change par rapport au rendu temps réel disponible sur
beta.letuffe, est l'utilisation de lighttpd et de python-fastcgi, plutot
que l'implémentation python d'apache2. Je ne me suis pas encore lancé
dans un benchmark entre les deux solutions logicielles.

 Quand tu dis dispo en ipv6, ça veut dire uniquement en ipv6 ?
 

Uniquement, mais c'est surtout par flemme de devoir rebooter la freebox
pour avoir une redirection du port 80 sur le serveur en question ;-)

-- 
Pierre



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] [Technic] Serveurs

2009-06-21 Par sujet Yann Coupin
Bon puisqu'on en est à discuter choix techniques, moi j'ai tenté apache 
+cgi et c'était assez lent. Du coup pour m'éviter les fork en pagaille  
j'ai décidé de tenter qqc de plus radicale et j'ai codé un serveur web  
en python via BaseHTTPServer et le module multiprocessing pour  
utiliser tous les core de mon CPU, ça marche bcp mieux me semble-t-il.

Mais à mon avis là où il y a vraiment moyen de gagner en perf c'est  
dans le fichier de style de mapnik, à chaque fois que je le regarde  
j'ai le yeux qui piquent tellement ça me semble inefficace. Entre les  
select qui remontent l'intégralité des 3500 colonnes de certaines  
tables pour n'en utiliser au final que 4 ou 5 ou les différentes layer  
qui refont à peu près les mêmes requêtes au lieu de ne faire qu'une  
couche en mutualisant les styles, je pense qu'il y a bien moyen de  
gagner du temps !

Yann

Le 21 juin 09 à 23:16, Pierre Mauduit a écrit :

 Une des choses qui change par rapport au rendu temps réel disponible  
 sur
 beta.letuffe, est l'utilisation de lighttpd et de python-fastcgi,  
 plutot
 que l'implémentation python d'apache2. Je ne me suis pas encore lancé
 dans un benchmark entre les deux solutions logicielles.


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr