nginx-etag-module : module de gestion des etags pour Nginx
- Samedi 4 septembre 2010
- Publié dans Administration . Hébergement . Réalisations
- Par Boris HUISGEN
- Ecrire
Le protocole HTTP définit un mécanisme de cache par validation des ressources Web : les Entity Tags. Son intérêt est d’autoriser les requêtes conditionnelles afin d’optimiser la gestion de la bande passante des clients et des serveurs Web. Ainsi, à chaque requête, le serveur calcule et ajoute un Etag, matérialisé par un identifiant unique associé à la ressource et à sa version.
En pratique, la première requête envoie le statut HTTP 200 – OK et l’etag calculé par le serveur. Si le client demande à nouveau la ressource et s’il soumet en information l’etag précédent, le serveur est capable de déterminer sa validité. Si les etags matchent, la ressource est à jour côté client et le serveur renvoie un statut HTTP 304 – Content Not Modified sans les données. Les Etags sont donc un moyen simple et fiable de gestion cache des ressources.
Je vais vous présenter le module que j’ai développé pour effectuer ce job sous Nginx : ngx-http-etag-module. Le calcul de l’etag est indépendant du filesystem afin de permettre une utilisation en cluster. A cela, j’y ai couplé une option permettant de forcer le calcul sur un fichier précis, quelque soit la ressource statique demandée. C’est cette raison qui m’a incité à développer ce module, car elle me permet de conserver le cache des proxys frontaux suite à une mise à jour des fichiers. Seul un touch sur le fichier permet d’invalider l’ensemble du cache et propager les modifications.
Installation
$ git clone git://github.com/bhuisgen/nginx-etag-module.git ./nginx-etag-module Initialized empty Git repository in /private/tmp/nginx-etag-module/.git/ remote: Counting objects: 21, done. remote: Compressing objects: 100% (21/21), done. remote: Total 21 (delta 6), reused 0 (delta 0) Receiving objects: 100% (21/21), 4.62 KiB, done. Resolving deltas: 100% (6/6), done. $ cd nginx-etag-module/
Le code de Nginx doit également être récupéré, compilation statique oblige :
$ wget http://nginx.org/download/nginx-0.7.67.tar.gz --2010-09-03 20:35:46-- http://nginx.org/download/nginx-0.7.67.tar.gz Résolution de nginx.org (nginx.org)... 81.19.68.137 Connexion vers nginx.org (nginx.org)|81.19.68.137|:80...connecté. requête HTTP transmise, en attente de la réponse...200 OK Longueur: 608462 (594K) [application/octet-stream] Sauvegarde en : «nginx-0.7.67.tar.gz» 100%[=================================================================== =======================>] 608.462 64,9K/s ds 8,5s 2010-09-03 20:35:54 (70,0 KB/s) - «nginx-0.7.67.tar.gz» sauvegardé [608462/608462] $ tar xzf nginx-0.7.67.tar.gz $ cd nginx-0.7.67 $ ./configure --add-module=../
Le script configure doit détecter la présence du module :
adding module in ../ + ngx_http_etag_module was configured
Comme d’habitude, compilation puis installation :
$ make $ sudo make install
Configuration
Pour activer la prise en charge des etags :
server {
listen 8000;
server_name localhost;
root /usr/local/www/html;
index index.php;
location / {
etag on;
}
location ~ \.php$ {
include fragments/php.conf;
}
}
Pour rediriger le calcul des etags sur un unique fichier :
server {
listen 8000;
server_name localhost;
root /usr/local/www/html;
index index.php;
location / {
etag on;
etag_file /opt/local/var/www/etag_file
}
location ~ \.php$ {
include fragments/php.conf;
}
}
Exemple :



Merci beaucoup pour ce plugin et…
Et très bon blog au passage, tu es dans mes flux de sysadmin :)
Ha une question en faites, j’utilise une infra openvz, j’ai des nginx en backend et un en front aussi !
Je voudrais savoir où je dois le mettre, les 2 ? Que le front ? Le back dans chaque container ? Actuellement je l’ai mis sur le front, front qui proxypass sur les containaire donc, je vois bien l’etag dans les headers, par contre rien dans le fichier etag_file.
Si tu peux m’en dire plus afin de ne pas faire n’importe quoi et bien gagner en perf :)
Merci d’avance :D
@Cyril
Il faut l’activer uniquement sur les backends car l’etag sera propagé, à moins de le supprimer au niveau suivant.
L’option etag_file permet de déporter le calcul de l’etag sur un seul fichier au lieu des fichiers demandés. Dans le cas où tu l’actives sur tes backends et si tu modifies des images par ex, et sans modifier le fichier déclaré, les modifications ne seront pas propagées au proxy front qui n’invalidera pas son cache. Tu peux t’amuser à gérer les headers, je crois qu’il y a un module exprès pour Nginx pour en injecter et il y a des options de base pour les supprimer.