Pour bien fixer les esprits, je vais prendre un exemple proche de nos préoccupations quotidiennes de bloggeurs ;D : la vérification des referers.

Si vous enregistrez le referrer de chaque requête dans le but de l’afficher dans vos stats publiques, vous vous êtes sans nul doute déjà confronté au besoin de vérifier que le référant pointe bien vers votre site avant de le valider, ceci afin d’éviter le “referer spam”. Il en est de même pour le comment spam.

Pour ce faire, vous devez déclencher une “contre requête” HTTP afin de récupérer et analyser la page référente. Cette opération est longue et ralentit d’autant le traitement de la requête d’affichage de votre page.

Certes, vous placerez judicieusement cette requête à la fin de votre page et déclencherez l’envoi de la page vers le client avant de commencer l’opération de vérification. Mais la connexion HTTP reste ouverte et le browser client indique qu’il continue de charger. A la limite, un utilisateur lambda pourra ne pas s’en rendre compte. En revanche, un robot d’indexation aura vite fait de classer votre site dans la catégorie des mammouths lents à la détente et donc à ne pas indexer trop fréquemment.

La chose se complique encore dans le cas d’un traitement plus évolué tel que l’enregistrement d’un nouvel article. Non seulement vous allez le stocker dans la base de données locale mais vous allez déclencher toute une série d’opérations en “cascade”. Exemples:

  • Génération de pages statiques
  • Trackbakcs
  • Pingbacks
  • Pings de mise à jour d'annuaires
  • Envoi de mails aux abonnés
  • Syndication en mode PUSH

(Liste non exhaustive… :»)

Avec une plateforme web basique (type PHP, ASP, etc…) vous laissez mouliner et vous partez boire un café (si vous êtes moins feignant, vous ouvrez une autre fenêtre). Bien évidemment, vous pouvez bidouiller. Qui a dit “pop-under”? Mais ce genre de solutions où l’on compte sur les capacités de scripting du client pour assurer la cohérence des traitements sur le serveur est vraiment tout sauf recommandable. >:XX Tout celà reste acceptable dans le cadre d’un site web perso (et à budget limité), pas dans un contexte professionnel, ni avec un minimum d’ambition.

Une plateforme telle que J2EE (à ne pas confondre avec un simple script Java) ou .NET (à ne pas confondre avec un simple script ASP) permet de traiter ce type de problème de manière tout à fait élégante.

Pour faire simple et parce que ce post commence à être long, tous les traitements énoncés ci-dessus vont être passés à une (ou plusieurs) file de messages. Cette “message queue” fera exécuter les traitements annexes et non “urgents dans la seconde afin de répondre à la reuqête” par un composant dédié à cette tâche et travaillant de manière asynchrone.

Un autre exemple est le déclenchement sans intervention de l’utilisateur de tâches telles que l’envoi d’emails de résumés quotidiens, la réindexation périodique ou encore la génération de snapshots statiques à intervalles réguliers.

Alors évidemment, les message queues et les traitements asynchrones peuvent parfaitement cohabiter à côté de technologies que j’ai qualifiées de “basiques” telles que PHP. Mais on est déjà là en train de construire une plateforme plus évoluée qui n’a plus rien à voir avec ce que l’on trouve chez un hébergeur low-cost par exemple. C’est le début d’une grosse machinerie… et on aura vite fait de préférer une machinerie standardisée, documentée et maitrisée par un certain nombre de personnes (J2EE, .NET) plutôt qu’une machinerie propriétaire, issue d’un individu isolé, aussi géniale soit-elle.

Comments from long ago:

Comment from: padawan

Intéressant, mais :

  1. il faudrait développer un peu en quoi J2EE/.NET sont plus “standardisés, documentés et maitrisés par un certain nombre de personnes” que PHP
  2. je sais faire de l’asynchrone avec du PHP, pas besoin de me sortir l’artillerie lourde là non plus ;-)
  3. faut que je fouille un peu, mais ça m’étonnerait qu’il soit impossible de trouver un exemple de referrer-log en open source “artisanal” qui ne pénalise pas les requêtes… John Gruber et Mark Pilgrim en ont un, ils sont tous les deux sous MovableType et ça m’étonnerait vraiment qu’ils l’aient fait avec du J2EE ou du .NET :-)

Allons, allons, les artisans ont encore un peu de répit avant de disparaître au profit des élevages de développeurs en batterie ! Essaye encore :-)

2003-11-17 15-52

Comment from: François PLANQUE

okay:

1: J2EE est plus standardisé parce qu’il draine derrière lui un nombre d’acteurs et de contributeurs bcp plus important que PHP. (.NET c’est uniquement une question de pognon et de puissance marketing :P) mais ce n’est pas là mon propos! Ce que je dis c’est que la plateforme J2EE ou .NET intègre des services en standard dont PHP ne dispose pas, sauf ajouts extérieurs, donc non standards.

2: moi aussi, mais encore une fois, avec des ajouts externes (disons cron), donc non standards, donc non portables d’un hébergeur à l’autre… (en supposant que je trouve des hébergeurs low-cost permettant de le faire). Dans tous les cas, on frise la bidouille.

3: je ne connais pas assez bien MT ni les solutions de John & Mark pour trancher sur le fait qu’il s’agisse soit de bidouille, soit, au contraire, que l’on puisse effectivement envisager MT comme une plateforme industrielle (fût elle low-end).

2003-11-17 16-33

Comment from: padawan

  1. d’accord, encore que pas mal de ces standards sont encore à moitié cuits et loins d’être matures. Il faut aussi admettre que PHP évolue de plus en plus vers un modèle de ce type (PEAR, c’est certes “greffé” mais ça va dans le bon sens, PHP5 s’inspire beaucoup de Java). En fait, j’ai l’intuition que dans quelques années, PHP sera arrivé à la cheville de Java sur tous les points qu’on lui reproche aujourd’hui, et s’il conserve sa simplicité de mise en oeuvre, il continuera à tailler des croupières à Java.

  2. oui et non, ça dépend. On peut faire de l’asynchrone en pur PHP, pas besoin de demander la permission à l’hébergeur :-). Faux problème de toute façon, parce que dans peu de temps, les serveurs virtuels (avec accès root complet mais partage physique de la même machine) seront aussi répandus que l’hébergement mutualisé d’aujourd’hui.

  3. on dira que c’est de l’artisanat plutôt que des bidouilles :-) parce que ces deux sites fonctionnent très bien (et sans spam à ce que je vois). Mais ce n’est pas lié à MT en fait, c’est du développement custom.

2003-11-17 18-20

Comment from: pk

A mettre en relation avec un article de Joel On Software : http://www.joelonsoftware.com/articles/Craftsmanship.html . Où on reparle de ’l’artisanat’ en informatique : lui est très loin de l’industrialisation du code. Si mes souvenirs sont bons, ils utilisent la plupart du temps VB qui est largement suffisant la plupart du temps.

A noter les différences qu’il fait entre plusieurs mondes informatiques où les données de départ ne sont pas les mêmes : http://french.joelonsoftware.com/Articles/FiveWorlds.html .

2003-12-08 12-48