L'architecture d'un blog performant
J'ai longuement cherché à optimiser les performances de ce blog pour que mon serveur puisse tenir une charge plus importante de visites et pour que les temps de réponse du serveur soient satisfaisants.
Suite à ces longues réflexions, voici une proposition d'architecture basée sur l'utilisation de Lighttpd et Memcached.
[
1 - Requête HTTP
La requête HTTP est envoyée par le navigateur du visiteur, elle traverse internet et arrive au niveau de votre serveur Web en quelques millisecondes.
Dans cette requête HTTP, on retrouve une quantité importante d'informations utiles pour répondre à bien à la demande : nom de la ressource demandée, contenu du cache du navigateur, support du gzip, le user-agent (téléphone mobile ou non) ....
Votre serveur Web et l'applicatif déployé doivent tenir compte de l'intégralité des informations transmises pour pouvoir répondre d'une manière pertinente à la demande.
2 - Serveur HTTP / Script LUA
Dès la requête reçue par le serveur HTTP, le monde idéal est de pouvoir répondre à cette requête sans devoir solliciter le backend PHP. En évitant de solliciter le backend, on économise ainsi du CPU et on libère worker PHP d'une tâche potentiellement inutile, celle d'aller vérifier dans le cache si la ressource est présente.
Pour les ressources statiques telles que les images, les scripts javascripts, les CSS, cela va être très simple, le serveur Web va s'en charger tout seul.
Si votre serveur est correctement paramétré, il devrait retourner un code HTTP 304 si l'utilisateur est venu précédemment sur votre blog, le cas échéant il retourne ressource "gzippée" pour économiser en bande passante et envoie un header HTTP "Expire" dans sa réponse pour indiquer au navigateur que cette ressource peut être gardée en cache.
Si la ressource demandée n'est pas une ressource statique, c'est à ce moment que le "mod_magnet" intervient. Ce module fourni avec Lighttpd permet de mettre en place simplement des scripts intelligents qui vont être capable de prendre une décision concernant la livraison de la ressource demandée: S'agit-il d'un POST ? D'un GET ? Avec des paramètres ? Est-ce que la page demandée est dans le cache mémoire ?
3 - Cache mémoire Memcached
Dès que le script LUA a pris la décision que la ressource LUA peut être dans le cache mémoire, il se connecte au Memcached et demande la ressource ayant comme clef le MD5 de l'URL de la ressource demandée.
Si cette ressource existe, le script LUA vérifie la présence headers HTTP "Etag"et "Last-modified-since" et décide de renvoyer le contenu Gzippé de la ressource si ces headers sont absents ou s'ils ne correspondent pas à la ressource récupérée du cache.
Si jamais cette ressource n'existe pas, alors le script LUA prend la décision d’appeler le backend PHP pour demander la production la ressource demandée.
4 - Excécution des scripts PHP
L'exécution du Backend se met en route, les scripts PHP sont récupérés du cache APC pour éviter une réinterprétation complète des scripts de la solution de blog utilisée.
La page demandée est générée à partir des données extraites de la base de données. Cette page est mis en cache pour une future utilisation par un autre utilisateur et envoyée au browser.
Cette réflexion rejoint le diagramme d'état que j'ai publié il y a un an, à la différence près que la prise de décision et la récupération des données du cache est réalisée par le serveur Web et non pas le script PHP.
- L'autre alternative à Lighttpd est Nginx + PHP-FPM
- Des scripts LUA compatibles avec Wordpress sont disponibles sur le forum Wordpress
