S'abonner au Flux RSS

mardi, mars 11 2014

Debian, PG9.3, Osmosis et Nominatim

Même en se basant sur des références en terme de stabilité il peut arriver que certains combos soient fatals à votre production. C'est ce qui m'est arrivé récemment pour un serveur Nominatim installé pourtant sur une Debian Wheezy, osmosis est utilisé pour la mise à jour continue de la base Nominatim et m'a fait des misères que je m'en vais vous conter.

Lire la suite...

jeudi, mars 6 2014

rosarks.eu

Je profite d'avoir la chance de pouvoir ré-écrire Lolix from scratch pour penser aux fonctionnalités qu'il m'aurait plu d'avoir quand je cherchais un travail, sur ce point j'ai toujours été surpris de voir à quel point les entreprises font bien peu d'effort pour aider les candidats à trouver leur locaux. Peut-être que les recruteurs imaginent que tout le monde sait où se trouve leur bureau, ou parce qu'ils imaginent cela comme une première épreuve pour mesurer le niveau de débrouilliardise du candidat, en tout état de cause personnellement je trouve qu'indiquer la sation de bus/tram/métro/vélocation à proximité ne peut être qu'un plus sur une offre d'emploi.

Lire la suite...

lundi, février 10 2014

OSM Pulsation

Je maintiens à jour une base de données pour Nominatim en utilisant les delta toutes les minutes, je me suis dit qu'il serait amusant de voir l'évolution des données au cours de la journée.

Lire la suite...

mardi, février 4 2014

Montée en charge de Wordpress

Dans la famille des tests de performance, le test de montée en charge consiste à tester un système avec un volume de données croissant afin de déterminer son comportement dans le temps, il est parfois aussi appelé test de vieillissement mais quelque soit son nom il a pour but de rassurer l'utilisateur sur l'utilisation à venir d'un outil. Tout ceux qui ont fait du développement et de l'exploitation de système d'information comportant une base de données savent bien ce qu'implique une augmentation du volume de donnée traité. Un index mal placé ou non utilisé et les temps de réponses croissent au fil des jours pour arriver parfois à un blocage complet du système. Il est pourtant simple de se protéger de cela en effectuant en pré-production des tests de montée en charge afin de mesurer les temps de réponse en fonction du volume de donnée dans le système.

Lire la suite...

lundi, février 3 2014

Nouvelle année, nouveau projet

Bien que je sois déjà fort occupé avec Lolix et mes missions en cours, j'ai pu prendre le temps ce WE (plutôt cette nuit) de mettre en forme une vieille idée et de lancer ce projet qui me tient à coeur depuis de nombreuses années. Alors si vous aimez le logiciel libre et avait envie d'en faire dans une ambiance détendue et productive je vous invite à prendre connaissance de peerweek.

mercredi, décembre 11 2013

Merci pour Lolix

La campagne de financement participatif pour financer Lolix V2 dépasse toutes mes espérances, je suis ébahi par l'engouement créé. Bien sûr j'ai toujours cru dans les forces de la communauté du libre mais je ne la pensais pas si attachée à ce projet.

L'objectif de la campagne a été atteint en 24h alors que la campagne va durer 42 jours ! Je croyais en la réussite mais pas avec une telle rapidité.

Mais que va-t'il se passer ces 40 jours restants ?

Tout d'abord je vais faire un dernier monkey patch sur le code de Lolix pour rouvrir le service le plus vite possible, au plus tard ce week-end. Ensuite la campagne comme c'est la règle sur Ulule va continuer jusque la date buttoir du 20 janvier ; bien sûr je ne vais pas attendre cette date pour m'attaquer au nouveau code, mais je vais prendre le temps, pas d'affolement donc si je ne réponds pas aux PR dans la journée ; sans compter que je suis aussi en mission en parallèle en journée. Je vais réflechir aussi à de nouvelles contreparties pour remercier tous les participants, une partie des fonds sera utilisées pour rémunérer un graphiste (si vous en connaissez qui travaillent sous Gimp je prends les noms) mais j'ai encore plein d'idées de goodies rigolo en tête.

Je vais également profiter de cette période pour voir comment impliquer un peu plus les sociétés dans la campagne, car à de rares exceptions près les grands recruteurs ne ce sont pas encore manifestés, l'administratif est toujours un peu plus lent à se mettre en branle, gageons que cela soit la raison de leur absence aujourd'hui.

Un grand bravo à vous, un grand merci à tous et longue vie à la belle Lolix !

vendredi, décembre 6 2013

Lolix de 1998 à 2013

Afin de bien comprendre ce qui se passe il est nécessaire de revenir un peu sur ce qui s'est passé depuis 15 ans, oui vous avez bien lu 15 longues années de bons et loyaux services à mettre au profit de Lolix. Après avoir vu ce qui s'est passé, compris ce qui se passe on va pouvoir parler de ce qui peut encore se passer.

Lire la suite...

jeudi, décembre 5 2013

Rejoindre la GeoTribu

C'est avec plaisir que j'ai rejoint cette semaine la joyeuse équipe de la GeoTribu ; je publierai désormais mes articles liés à la géomatique sur www.geotribu.net et continuerai par contre à publier ici tout ce qui est lié à mon activité sur les tests de performance et mes contributions à Tsung.

Je vous laisse le soin de découvrir le premier billet publié intitulé Temps de réponses comparés OSRM vs GraphHopper

samedi, novembre 30 2013

Utiliser GraphHopper avec Jetty8 sous Debian

Actuellement la seule solution documentée pour utiliser GraphHopper est l'utilisation de jetty runner, celle-ci n'est pas satisfaisante dans un mode de production, elle requiert de mettre en place des scripts de lancement. Il est plus simple d'administrer un service de routing en utilisant par exemple jetty ou Tomcat, ce billet va se concentrer sur la configuration de jetty sous Debian Jessie.

Tout d'abord installer le serveur jetty

apt-get install jetty8

Puis on récupère l'archive .war que l'on copie dans le répertoire de webapp de jetty

cd /var/lib/jetty8/webapps
wget http://oss.sonatype.org/content/groups/public/com/graphhopper/graphhopper-web/0.2/graphhopper-web-0.2.war

Toujours dans le répertoire webapps on va renommer le fichier war de GraphHopper afin que le déploiement se fasse dans le contexte racine, de même que l'on va supprimer le répertoire existant nommé root. La raison de cette opération peu orthodoxe est que par défaut GraphHopper répond aux requêtes d'api sur l'url /api/ et qu'il n'est pas actuellement possible de paramétrer cela simplement. La seule méthode de contournement est d'indiquer un paramètre host dans l'url ce qui n'est pas des plus ergonomique.

mv graphhopper-web-0.2.war ROOT.war
rm -fr root/ 

On va déployer les fichiers de configuration et de données dans /home/routing, il faut créer ce répertoire, dans lequel on en crée de suite un autre nommé data qui contiendra les données précompilées par GraphHopper

mkdir /home/routing
mkdir /home/routing/data/

On crée un fichier de configuration dans le dossier en utilisant l'exemple fournit sur le site du projet, fichier que l'on renomme dans la foulée.

wget https://raw.github.com/graphhopper/graphhopper/master/config-example.properties
mv config-example.properties config.properties

Maintenant on va récupérer le fichier qui servira de source de données, on télécharge directement un fichier protobuff depuis le site de Geofabrik, par exemple le fichier de données de la région Nord-Pas de Calais :

wget http://download.geofabrik.de/europe/france/nord-pas-de-calais-latest.osm.pbf

On édite le fichier de configuration pour qu'il corresponde à notre utilisation en ajoutant deux paramètres à la fin de celui-ci. Le premier qui correspond au fichier protobuff utilisé et le second qui indique où GraphHopper doit créer ses fichiers de données.

# data source
osmreader.osm=/home/routing/nord-pas-de-calais-latest.osm.pbf
# repertoire de données
graph.location=/home/routing/data/

Au lancement de jetty GraphHopper va pré-traiter les données du fichier .pbf afin de préparer ses tables de recherches qu'il stockera dans le répertoire /home/routing/data/ Si vous voulez mettre les données à jour il suffit télécharger un nouveau fichier de données et de relancer jetty, le fichier de données étant plus récent GrapHopper relancera une analyse.

Le serveur jetty tournant sous Debian avec l'utilisateur jetty il faut définir les bons attibuts de propriété aux répertoires ainsi qu'à tous les fichiers présents dans celui-ci.

chown -R jetty.jetty /home/routing

Dernière modification, éditer le fichier /etc/default/jetty8 pour paramétrer le démarrage automatique et indiquer le fichier de configuration de GraphHopper

# change to 0 to allow Jetty to start
NO_START=0

# Additional arguments to pass to Jetty    
JETTY_ARGS=-Dgraphhopper.config=/home/routing/config.properties

Par défaut comme souvent sur Debian le démon va écouter seulement sur le localhost, à vous de régler le paramètre JETTY_HOST suivant vos besoins.

Il ne reste plus qu'à lancer jetty avec le script d'init avec l'utilisateur privilégié root

invoke-rc.d jetty8 restart

A ce stade GraphHopper est prêt à répondre sur le port 8989 de votre machine et à vous indiquer la route !

mardi, novembre 26 2013

Test de GraphHopper

GraphHopper est outil de routage comme OSRM qui a été traité dans un précédent billet.

La sortie hier la version 0.2 est l'occasion de tester ce nouvel outil, dont le développement a été commencé il y a un peu plus d'un an, et de le comparer à OSRM.

L'environnement de test est comme à mon habitude une distribution Debian, afin de minimiser le travail de déploiement on va se reposer au maximum sur les paquets. Graphhopper requiert une version 7 ou 8 de JRE, ce qui va nous obliger à utiliser la version testing aka Jessie, il faut tout d'abord installer le paquet default-jre.

apt-get install default-jre

La suite de la procédure décrite dans le Quickstart est claire et permet le lancement de GraphHopper après quelques récupérations de fichier en ligne dont jetty runner et le war de GraphHopper. La méthode de déploiement avec jetty runner est peu propice à une mise en production bien que fonctionnelle, j'ai bien essayé de déployer le .war avec Jetty ou Tomcat7 mais en vain, n'étant pas un expert java cela semble normal ; il sera sage d'attendre un peu de packaging autour de l'outil avant d'en envisager une exploitation sereine.

Le résultat obtenu diffère de OSRM qui ne fournit qu'une API quand GraphHopper propose une solution tout en un, on obtient directement une interface web interrogeable sur le port configuré (ici 8989), il est également possible d'interroger directement l'API sur l'url /api/route, pour un aperçu le résultat est identique à la démo en ligne. Basé sur Leaflet la fond de carte est agréablement complété d'un cadre matérialisant la bounding-box des données traitées.

Autre différence notoire est le temps de préparation des données, bien que l'on travaille directement avec des fichiers .pbf dans les deux cas sans passer par une base de données, GraphHopper comme osrm nécessite de construire les arbres de données. GraphHopper fait ceci directement lors du lancement quand osrm nécessite de passer par les étapes osrm-extract et osrm-prepare.

La différence majeure va venir du temps de précompilation, sur une machine avec 6 core, 12Gb de RAM et des disques SSD j'ai obtenu les résultats suivants. J'ai utilisé une première fois le fichier de la ville de Berlin et en second celui de la France, tous deux obtenus sur Geofabrik.

BerlinFrance
GraphHopper17 sec 32min
osrm37sec71min

Le résultat est assez net, le temps de précompilation des données est deux fois inférieur avec GraphHopper ce qui lui donne un avantage considérable pour qui voudrait mettre à jour ses données régulièrement sur une emprise de taille conséquente.

La prochaine étape sera de mesurer les temps de réponses des deux API, ce que je vais m'employer à faire rapidement avec Tsung, je publierai les résultats ici.

- page 1 de 12