Sites à gros trafic : PHP, RoR, il y a encore des progrés à faire

PHP et le multi-threading

Je discutais avec un copain au sujet d'une redirection 404 (pour l'existence ou non d'un fichier) sous Apache, la solution serait de rediriger vers une page PHP (en fait, la bonne solution serait d'utiliser les rewriting rules, dont ce n'est pas le sujet ici). Cet ajout de page paraîssait poser un problème de performances (sous eZPublish le bien nommé, sur un site à fort trafic). Je googlise pour voir Apache, et ses modes d'exécution. 2 modes : MPM prefork ou MPM worker, le 1er hérité de la version 1.x, le 2è, nouveauté de la version 2.x d'Apache, et permet le multi-threading, ce qui est bien mieux au niveau de la consommation de ressources (mémoires notamment) et des performances d'exécution.

Lighty est souvent conseillé pour répondre aux problèmes de perf. d'Apache, ou Nginx pour servir des fichiers statiques, ce dernier étant très performant pour remplir cette fonction...seulement ils n'offrent pas toutes les capacités des rewriting rules, dilemme.

Pour rappel, Apache a un pool de process, pour chaque requête HTTP (ou ~session). Sur un site à fort trafic, on imagine très vite le coût que va demander l'ensemble des process du pool (ajusté en conséquence) en termes de mémoire, le mode worker (multi-threadé) serait alors plus approprié, et est une évidence évidente comme dirait ma femme. Le mode worker doit être précisé lors de la compilation, prefork étant le mode par défaut founi (voir cet intéressant article), mais le seul problème étant que PHP 5 n'accepte pas par défaut le multi-threading (il n'est pas thread-safe)...sic...obligé d'utiliser l'ancien, le très old-school prefork, à moins d'utiliser FastCGI, ce qui n'est pas représentatif de l'ensemble des LAMP - comme on risque de me sortir ben si, regarde Facebook, eux, c'est du PHP...sans doute oui, mais leur infrastructure a été réglée aux p'tite oignons pour répondre à la charge.

Je trouve ça très (très) étonnant et fou qu'à notre époque, qu'une techno. ne puisse pas gérer de façon simple (ie : qu'il faille déployer une énergie sans limite pour régler ça...) la problématique du multi-threading, la base de toute plateforme Web, qu'on me l'explique SVP.

Rails

Sur les différents blogs que je visite, revient régulièrement la question de performance, des problèmes de stabilité du serveur Web ou des soucis d'hébergement mutualisé (ie : comment relancer une application sans relancer tout le serveur Web...et donc toutes les applis. sur celui-ci). Même si des solutions se profilent à l'horizon pour régler les questions de consommation de ressources ou de mutualisation de sites par le biais de mod_rails , même si certains sont moins optimistes.

Je ne voudrais pas jouer les Cassandre, mais pour comprendre, qui pourrait m'expliquer pourquoi en 2008, toutes ces questions de perf., stabilité, hébergement ne soient toujours pas résolus, qu'il faille dépenser beaucoup de temps pour régler ces points, afin d'arriver à un niveau d'industrialisation / de production des applications Web suffisant (et nécessaire). Même si des expériences, des tentatives, des essais sont engagés, pourquoi cela parait-il si compliqué ? Est-ce tout compte fait une Arlésienne les promesses de DHH, un coup marketting monté en mayo par des killers applications, comme le soupçonnent certains ?

.NET Performer

Dernière petite chose, que j'avais dans mes innombrables favoris, un plugin Rails pour le 1er avril 2008 qui simule le modèle ASP.NET, un brin d'humour, mais beaucoup d'ironie voire du cynisme...quelques réponses aux points soulevés par l'article.

En préambule, l'auteur a bien eu raison après 5 ans d'abandonner .NET, être mauvais dans une techno. c'est une chose, ne pas l'admettre, c'est de la mauvaise foi. Pour sa décharge, sans doute qu'il venait du monde PHP et qu'il a, sans réfléchir ou par manque de temps, voulu appliquer le modèle PHP à celui d'ASP.NET, càd. développer des pages ASP.NET comme on en développe en PHP, autrement dit, de la mauvaise manière.

• Feature 1 : Viewstate : dans les pages consultatives, on le désactivera bien évidemment - même sur certains formulaires, on pourra également s'en passer, et on remerciera le PostbackData qui permet en grande partie de faire persister les valeurs d'un formulaire (Textbox, ...). Pour rappel, le Viewstate permet de conserver les valeurs des données des contrôles lors du POST de la page (ie : propriétés déclarées dans ces derniers ou celles sauvées manuellement comme stockage). Un excellent article sur le sujet : Le Gray's Anatomy du Viewstate qui met fin à toute ambiguité et surtout certaines idées reçues véhiculées, et on pourra toujours le compresser si besoin, même si avec une bonne utilisation du Viewstate devrait suffire.
• Feature 2 : dans un environnement en production, on pensera bien évidemment à se brancher sur l'évènement Error de la page (on pourra créer une classe mère utilitaire pour déployer à l'ensemble des pages qui hériteront de cette classe cet évènement) : cela a le mérite de pouvoir faire une belle page "Veuillez nous excuser, bla, bla" à la charte pour l'afficher aux internautes, et entre-temps de nous envoyer par mail, toute la pile de l'erreur survenue, la page, l'id de l'utilisateur le cas échéant, ni vu, ni connu, tout le monde y trouve son compte.
• Feature 3 : différents points de vue sur le moment de valider une saisie : est-ce aux entités de l'ORM de le faire (ie : ActiveRecord), ou bien la couche présentation ? je suis d'avis (forcément) de les contrôler sur le formulaire - même si on pourra discuter du pour ou contre - on fera évidemment un contrôle réutilisable pour gérer l'affichage des erreurs (ok, ko). Les entités étant utilisables dans l'absolu ailleurs que la couche présentation, je compte plutôt sur les contraintes d'intégrité, dont c'est le travail, pour me vérifier la cohérence de mes données. En amont, bien entendu, on ne fera jamais confiance envers l'utilisateur et les données saisies, les contrôleurs sont faits pour ça, de vérifier (un article intéressant sur ActiveRecord).
• Feature 4 : has been, voir WCF ou ADO.NET Data Services (codename Astoria). Dans l'absolu, en quoi gêne l'extension .aspx ?
• Feature 5 : has been - ce n'est plus le cas depuis 2005, les pages créées sont XHTML 1.0 compliant. En préviligierant l'utilisation des Masters Pages, qui permettent d'avoir un thème de page, et surtout d'avoir un layout uniforme pour toutes les pages qui se basent sur une Master Page.
• Feature 6 : sur la longueur des ID des contrôles : je lui accorde au moins ce point, qu'ASP.NET génère le nom selon l'arborescence est gênant du point de vue du nombre de caractères transférés. Mais bien sûr, le mauvais exemple est donné avec l'hidden, si on doit stocker des valeurs, autant le faire dans le Viewstate (optimisé en conséquence). Pour l'Ajax, avec Prototype, on accédera à la valeur d'un contrôle en utilisant $('<%=moncontrol.ClientID%>'). C'est bien mais pas suffisant. Pour une question de réutilisation, on veillera à développer des composants (ie : user controls) qui seront réutilisables soit dans l'application Web soit dans d'autres applications Web hébergées sur la même plateforme (en WAP . Ainsi nous ne serons pas dépendant d'une librairie Javascript, embarquée et générée pour la page utilisatrice du composant utilisant Ajax (encapsulation et abstraction). Les répertoires virtuels sont nos amis pour réutiliser des composants partagés entre applications).

Amusant, je donne gracieusement un cours sur les bonnes pratiques du modèle ASP.NET

Ceux qui prônent une idéologie philosophie soi-disante libre pensent bien souvent détenir LA vérité et l'unique voie à prendre, en deviennent à force arrogants voire intolérants et...aveugles, le propre des communautés ?

Diatribe finie - retour au mode constructif.