Ergonomie, Rails et Architecture de l'information web (2.0)

Pas de repos pour les braves en ce 14 juillet – normal il est hollandais, il n’en a donc pas grand chose à faire – puisque Hongli Lai vient d’annoncer la sortie de Passenger mod_rails 2.0.2, qui corrige un certain nombre de bugs critiques. Passenger est un module Apache qui rend le déploiement d’une application Ruby on Rails, mais pas seulement, aussi simple qu’un site en PHP, retirant la principale épine du pied de mon framework web favori.

Cette nouvelle version de Passgenger corrige en particulier une importante fuite de mémoire qui survenait chaque fois qu’un client web quittait le ApplicationPoolServerExecutable. Celle-ci, après avoir mis le serveur à genoux et rendu le site indisponible pendant un week-end entier m’avait finalement forcé à downgrader en 1.0.5 nettement plus stable.

Et comme une bonne nouvelle n’arrive jamais seule, cette version arrive avec un paquet Ubuntu tout chaud.

French version below

I’m repassing the bench since hardware configuration made the gap between the 2 Typo instances too wide

After deplying Ruby Enterprise Edition along with Passenger 1.9.0 on this server, Cyril Mougel and I have decided to bench his configuration versus mine.

Compte-rendu “live” de la session de ce premier Barcamp Paris Rails consacrée à Rails dans les environnements d’hébergement mutualisé que j’ai animé avec Nicolas Mérouze.

Problématiques soulevées :

• Partage des ressources (RAM et processeur) entre les différentes applications.
• Application web nécessitant un redémarrage à chaque changement en mode production, donc des privilèges élevés sur la machine.
• Complexité de mise en place pour un hébergement de masse, aux particuliers.

S’il existe un grand nombre de manières de déployer et de faire tourner des applications développées avec Ruby on Rail, comme, au hasard, ce blog, l’hébergement de masse reste encore un vrai problème, principalement pour des raisons de complexité de configuration côté serveur. L’absence sous Apache d’un modrails comme il existe un modphp y était certainement pour beaucoup, jusqu’à la sortie hier de Passenger, aussi appelé modrails. Enfin terminés les atermoiements entre mongrel + modproxy, ou fastcgi, avec tous les inconvénients inhérents à ces deux solutions. Il existe certes d’autres solutions logicielles, parmi lesquelles ma préférée va à Nginx + Thin, cependant quand on héberge des sites faisant très massivement appel à mod_rewrite, ces dernières sont malheureusement exclues (à moins que quelqu’un ne me porte les quelques 500 rewrite rules qui restent encore ici et là).

Mais sans plus attendre, rentrons immédiatement dans le vif du sujet, l’installation de mod_rails pour Apache 2 sous Debian.

Typo, le blogware en Ruby on Rails dont je suis mainteneur depuis un an et demi souffre malgré lui d’une réputation de bloatware, qui n’a – malheureusement – pas toujours été injustifiée, au point de lui coller à la peau comme le sparadrap du Capitaine Haddock. Un des très gros efforts du passage de la 4.0 à la 5.0 a porté sur une refonte complète de la back end afin d’en éliminer les lourdeurs.
Il semble que nous ayons réussi notre pari, comme l’explique cet article de Kevin Williams, utilisateur de Typo et heureux de l’être dont je vous donne la traduction ci-dessous :

Les problèmes de montée en charge sont choses courantes pour un site ou une application web une fois atteint un certain succès. Ces derniers sont bien trop souvent négligés, généralement jusqu’au jour où se trouve atteinte la limite critique entre l’inconfort et l’instabilité. Le trend actuel veut qu’il soit à la fois plus simple et moins cher de rajouter des machines que de reprendre son code en profondeur pour l’optimiser. Encore faut-il que l’application permette un redimensionnement de ce genre sans rentrer dans une phase de refactoring complet. Évidemment, avant d’en arriver à une solution aussi lourde, il vaut mieux s’assurer que tout a été fait pour exploiter au mieux les ressources disponibles, et cela passe notamment par un peu d’optimisation côté serveur.

Les problèmes de performances sur un site ou une application web proviennent plus souvent d’erreurs de développement que de soucis de montée en charge. Développée par Yahoo, Yslow, littéralement “pourquoi ça rame” est une extension Firefox qui permet d’effectuer des contrôles de performances sur 13 points clés d’un site web. Chaque point testé reçoit une note pouvant aller de A à F, et les problèmes rencontrés s’accompagnent de conseils tournés vers une optimisation du code. Plus la note est élevée, et plus votre site est rapide.

Pas moins de 13 points de contrôle

YSlow met en avant 13 bonnes pratiques fondamentales dans l’optimisation d’une page web :

1. Minimisez le nombre de requêtes HTTP.
2. Utilisez un réseau spécialisé dans la fourniture de contenus.
3. Ajoutez un en-tête d’expiration.
4. Compressez les contenus côté serveur.
5. Placez les feuilles de style en haut de la page.
6. Déplacez les Javascript en bas de page.
7. Proscrivez les expressions CSS.
8. Placez un maximum de javascript et de CSS dans des fichiers externes.
9. Minimisez les besoins en requêtes DNS.
10. Optimisez le javascript.
11. Évitez les redirections HTTP (301, 302).
12. Supprimez les scripts redondants.
13. Configurez les etags

Un premier test de performances me montre que la refonte en cours du site ne devra pas seulement être ergonomique ou graphique, mais qu’un gros travail d’optimisation est aussi nécessaire. Comme quoi les histoires de cordonnier…

Actualys, société de service parisienne spécialisée dans l’accompagnement des projets web en grands compte – qui s’équipera bientôt d’un site conforme aux standards – recherche actuellement un administrateur système UNIX indépendant connaissant bien les serveurs JBoss et Tomcat pour une missions de longue durée.

Ça y est, les grands travaux de rentrée sur ce blog me semblent terminés, du moins les plus gros, on n’est jamais à l’abri de petites retouches à faire ici et là. La preuve, le simple fait de les évoquer m’en fait venir deux ou trois à l’esprit.

Au menu des grands travaux, on a pu noter, dans le désordre :

Alexander Kirk propose un excellent document envisageant 10 pistes réalistes pour optimiser la rapidité d’un site Internet, et plus encore d’une application Web dont les besoins en réactivité égalent les applications en client lourd.