Voici un premier post focalisé sur mes tests liés à l’hébergement d’applications Rails.

Depuis quelques temps, je fais tourner mes applis de cette manière :

• un cluster de process Mongrel (5-10 en général)
• un virtual host Nginx qui fait proxy et load-balancer

Le principe est assez rigide ; on définit un pool de process Mongrel qui instancient chacun la totalité de l’application (et du framework) et qui ouvrent un port pour répondre aux requêtes. Le proxy/load-balancer redirige les requêtes du port 80 vers ces autres ports de manière transparente, récupère le résultat et le renvoie au navigateur à l’origine de la requête.

Cette allocation de process se fait de manière statique, au lancement du cluster. Il faut donc bien calibrer le nombre de process lancés car ça n’évolue pas selon la charge. Qu’il y ait 1 ou 1000 requêtes simultanées, le nombre de process ne change pas. Dans le premier cas, c’est de la RAM qui est utilisée pour rien, dans l’autre ce sont des requêtes qui font la queue.

Grace à un gabarit (très simple) de configuration du cluster, à quelques scripts de lancement et un chien de garde qui surveille tout ça (Monit est parfait pour ce job), tout roule assez vite et vraiment bien.

Cependant, c’est un sacré pas en arrière par rapport à l’hébergement d’applis PHP. Il suffisait de placer son code source dans un dossier accessible via un VirtualHost et basta !

Au printemps 2008, la communauté Rails a déclaré (RubyInside et LoudThinking) que l’absence d’un vrai mod_ruby (ou rails) pénalisait fortement l’adoption de l’outil. Je l’ai constaté par moi-même a chaque présentation, les remarques fusent sur la complexité de l’hébergement.

Alors quelques farfelus se sont lancés dans le développement d’un module pour Apache qui permettrait de déléguer à Apache la gestion des process (leur lancement/extinction selon les besoins, le nombre max de process par appli ruby…) et de se contenter d’un VirtualHost qui pointe vers le dossier principal d’une appli ruby.
Ce module a rapidement été surnommé “mod_rails” car il a assez vite permi de faire tourner des applis Rails, mais pas Merb, et autres framework à base de Ruby.
Son vrai nom est Passenger Phusion.
Depuis peu, il a atteint l’état “stable”, il permet de faire tourner d’autres framework… et il gagne du coup une sacré popularité, à tel point que moi qui suis plutôt conservateur quand les choses marchent vraiment bien, je me suis laissé aller à faire un premier test de config, mais surtout à un comparatif de performance pour charger la page d’accueil d’une même appli Rails dans les 2 modes d’hébergement.

Situation commune

La machine est quasiment au repos ; MySQL tourne mais aucune autre appli Rails que celle de test n’est en service, pas de process lourd (copie, backup, transfert…) au moment des tests.

Premier test : Nginx + Mongrel_cluster

J’ai mis en place un cluster de 30 process Mongrel et un VirtualHost dans Nginx pour le proxy/load-balancer. C’est ma config de prod courante (sauf que j’ai moins de process en général).

Un stress test avec ApacheBench :

$ ab -n 1000 -c 50 http://serveur.dev/accueil

Au résultat il a fallu 94 secondes pour répondre aux 1000 requêtes, avec une moyenne de 10,58 req/sec

Aucun autre process gourmand et inutile ne tournait sur la machine (Apache était arrêté).

Second test : Apache + Passenger

J’ai configuré un Virtualost dans Apache2 avec un nombre maxi de process à 30

Un stress test avec ApacheBench :

$ ab -n 1000 -c 50 http://serveur.dev:81/accueil

Au résultat il a fallu 88 secondes pour répondre aux 1000 requêtes, avec une moyenne de 11,25 req/sec

Nginx était stoppé.

Conclusion

De la simplicité de mes tests et de leur rigueur très relative, je tire tout de même une première conclusion : ça va pas moins vite !

Ce qui veut dire que c’est a priori une solution aui est envisageable, moyenant des tests plus poussés.

Le grand bénéfice de tout ça serait certainement d’alléger mon environnement de dev. Ne plus avoir à paramétrer un cluster, un VHost, Monit… pour une nouvelle instance de travail, ça sera un vrai progrès par le gain de temps.

Ensuite, pourquoi pas le mettre en environnement de production. La quantité de RAM dispo est assez importante, il suffit alors de permettre un grand nombre de process dynamiques pour que Apache s’adapte à la demande de manière plus souple.

Ça ne me fera pas changer d’avis quand à la qualité de Nginx en tant que serveur web ultra léger, particulièrement adapté pour les fichiers statiqueset très facile à configurer.