rails « Neomarco Insiders

Archive pour le mot-clef ‘rails’

Migration vers Passenger – Ruby Entreprise Edition

Dimanche 25 janvier 2009

Cet article est le second dans la série “Migration vers Passenger” dont vous pouvez commencer par le préambule.

L’utilisation de Passenger ne nécessite rien d’autre qu’Apache, mais il a été développé par une équipe qui a aussi travaillé à un fork de Ruby basé sur la version 1.8.6 officielle. On peut trouver tous les détails sur leur site. En gros c’est une série d’améliorations au niveau du “garbage collector” et de l’allocation mémoire. Ils prétendent qu’une application Ruby on Rails consomme 33% de mémoire en moins avec Passenger et REE qu’avec la machine Ruby officielle (MRI).

Bon, ben vu qu’on va utiliser Passenger et que la version Debian Etch de Ruby est assez ancienne (1.8.5), pourquoi pas utiliser aussi une version optimisée de Ruby.

Étant un utilisateur convaincu de Debian, j’ai pas trop envie d’utiliser des paquets compilés manuellement. Je préfère utiliser Apt pour gérer mes logiciels ou librairies installées, mais là il faut avouer que l’installation de REE est très simple et rassurante.

On télécharge les sources compressées et on lance simplement un script d’install qui se charge de tout avec un miminum de questions. Il installe par défaut le tout dans le dossier /opt/ pour respecter les conventions et il n’a besoin d’aucune dépendance externe.

Il faut ensuite indiquer à Passenger quelle version de Ruby utiliser. Là encore, l’install nous donne un bout de texte à copier/coller dans la config de Passenger.

Pour ce que j’ai pu en tester, ça a l’air de très bien fonctionner jusque là. J’ai même l’impression que les applis vont plus vite. Je ne sais pas encore précisément si c’est vrai ou pas, ni si c’est dû à la version de Ruby (1.8.6 au lieu de 1.8.5), à REE en soi, ou bien au remplacement de Nginx/Mongrel par Apache/Passenger.

Il y a quand même un petit hic, je trouve, dans ce monde de rêve : la gestion des gems.

TOUTES les gems doivent être re-installées via le binaire rubygems fourni par REE. Il faut donc repérer les gems (et leurs versions antérieures éventuelles) nécessaires et les installer avec un très long

$ /opt/ruby-enterprise-1.8.6-20090113/bin/ruby /opt/ruby-enterprise-1.8.6-20090113/bin/gem install XYZ

C’est assez casse pieds d’avoir à taper ces chemins d’accès à chaque fois, et puis à chaque mise à jour de REE (3 fois depuis octobre 2008) le chemin change (à cause de la date dans le chemin). J’ai donc fait un simple lien symbolique “/opt/ruby-ee” qui pointe vers la version courante.

J’ai pas encore réfléchi aux conséquences possibles d’un lien symbolique plus courant pour avoir REE à la place de Ruby globalement dans tout le système. C’est sûr queça serait pratique d’avoir le même Ruby pour l’appli web via Apache que via IRB ou la console de Rails (qui est IRB + le code de Rails chargé d’ailleurs). Mais pour le moment je peux supporter la coexistence de 2 Ruby sur la machine sans trop m’enmêler avec.

la suite : VirtualHosts

Migration vers Passenger – préambule

Dimanche 25 janvier 2009

Il y a quelques semaines, j’écrivais sur mon blog perso un article sur Passenger.

Depuis, la solution a continué de prouver sa stabilité. De plus en plus de grands noms ont basculé leur ancien système vers Apache + Passenger (aka mod_rails).

Ce qui jusque là était considéré comme LA meilleure solution pour héberger des applis Rails – Nginx + Mongrel cluster – est toujours une excellente solution ; rapide, fiable, … mais elle souffre tout de même d’une certaine complexité à laquelle on n’était plus habitué depuis la facilité d’héberger des applis web à base de PHP et consort.

On a démarré neomarco.com sur un système à base de Nginx + Mongrel cluster (entre 5 et 20 process Mongrel selon les moments). Y est adossé un superviseur (Monit) qui s’assure que les process sont bien en vie, les empêche de dépasser un certain seuil de mémoire, les redémarre si besoin, …

Chaque fois qu’on déploie une nouvelle version de l’appli, le cluster redémarre tous les process, Monit hurle que rien ne va plus et nous balance des dizaines de mails (pour de vrai). Il ne fait que son travail, mais là je suis au courant que le cluster redémarre, c’est moi qui ait appuyé sur le bouton ;-)

En plus, je suis obligé d’anticiper le nombre de membres dans le cluster ; trop c’est inutile et la ram est prise, pas assez et c’est la file d’attente comme à la Sécu pour les requêtes web. En plus il n’y a pas vraiment d’optimisation, tous les process Mongrel utilisent en Ram tout le code de Rails et de l’appli.

À l’opposé, Passenger (un module pour Apache, pour faire simple et rapide) permet d’éviter tout ça. Les process sont démarrés à la demande par Apache lui-même, la mémoire qui peut être partagée l’est, …

L’avantage c’est qu’en reprenant Apache comme serveur web principal, il redevient très facile d’héberger des applis non Rails, comme des blogs Wordpress, ou des forums, … alors qu’avec Nginx il fallait utiliser PHP en mode FCGI ou bien faire un proxy vers Apache sur un autre port.

Me voilà donc fortement motivé pour repasser mon système sur Apache + Passenger. Ce qui va suivre est un récit progressif (en plusieurs étapes certainement) de cette migration.

La suite : Ruby Entreprise Edition

Moteur de recherche géolocalisé

Lundi 19 janvier 2009

La nouveauté du jour, c’est la mise en ligne d’une nouvelle version des moteurs de recherche avancé des objets et des neomarco.

Avant

Un champ de texte libre permettait de chercher les mots clés dans tous les champs de texte des fiches (objets ou neomarco), y compris les champs d’adresse, ville, pays, …
Un menu déroulant permettait de restreindre à un pays.

L’inconvénient c’est qu’un recherche du type “vase paris” pouvait remonter des vases vendus dans une boutique sur le “boulevard de Paris” à Marseille ; pas très pertinent tout ça !

Après

Un champ de texte libre pour “quoi ?” permet de rechercher dans les champs de description de l’objet (ou du neomarco).
Un autre champ libre “ou ?” permet de restreindre sa recherche d’un point de vue géographique.

Ce sont les API de geocodage de Google et Yahoo! qui sont ici mises à profit pour transformer une demande de type “Paris”, “Indonésie”, “San Andreas, CA”, ou encore “3 place de l’église de St Henri, 13016 Marseille,  France” en un point GPS.

Selon la qualité du géocodage – du niveau national jusqu’au niveau de l’adresse postale – on détermine un rayon de recherche (qui peut aussi être forcé manuellement)

À partir de ce point GPS de référence et du rayon, on recherche dans la base de données les objets ou neomarco qui sont dans ce cercle.

Ce type de recherche est possible grace au fait que depuis le début on peut géolocaliser les objets que l’on dépose ainsi que sa propre fiche neomarco. Pour les fiches qui ne seraient pas localisées (c’était optionnel pendant plusieurs semaines) on a lancé un automate qui a automatiquement géolocalisé les fiches pour lesquelles les API ne donnaient qu’un seul résultat (pas de doute possible donc). Sur près de 3000 neomarco et 1700 objets, il y en a moins d’une dizaine à chaque fois qui ne peuvent pas être localisés.

Lors de la recherche, si la saisie de l’utilisateur ne donne pas qu’un seul résultat, une liste est proposée, il peut choisir et lancer sa recherche.

Plus tard

On aimerait afficher explicitement sur la carte des résultats le rayon de recherche. C’est tout à fait possible, reste à faire !

On souhaite aussi afficher des marqueurs photo (la vignette du neomarco ou de l’objet) plutôt qu’un marqueur générique.
Si vous avez déjà été sur http://panoramio.com/, vous verrez ce qu’on vise, mais là c’est beaucou plus dur.
En effet, Google a créé une couche de données supplémentaire sous forme de “Overlay” plutôt que des marqueurs. Ça leur permet d’affecter des actions Javascript, … sur les images mais la mise en œuvre est beaucoup plus complexe.

Actuellement les recherches de neomarco et d’objets sont séparées, on aimerait combiner les 2 moteurs.

Enfin, l’utilisation d’index plutôt que de faire des “Select * From … Where …” sur les tables de contenus permettrait de faire des classements par pertinence, de ne pas remonter bêtement “tableau” ou “respectable” lorsqu’on cherche “table”, … Pour ça a priori on va utiliser Sphinx et le plugin ThinkingSphinx pour Rails.