Accueil du site > Varnish > Interfacer Varnish & SPIP

Interfacer Varnish & SPIP

mardi 29 mars 2011, par Fil

Principe de communication

Les communications entre notre application (ici il s’agira surtout de SPIP, mais le principe vaut pour d’autres applications) et notre proxy inverse Varnish se font par l’entremise des entêtes HTTP émises par l’application.

Nous introduisons les header() suivants :

X-Varnish-TTL: 120
Cet entête indique que la page doit avoir un TTL, dans Varnish, de 120 secondes ; dans SPIP il sera émis dans les conditions suivantes :

implicitement, en prenant la durée de cache de la page : TTL = min(durée du cache, 600)
ou bien explicitement via la balise #HTTP_HEADER{X-Varnish-TTL: 120}

L’appel #HTTP_HEADER{X-Varnish-TTL: 0} permet de dire à Varnish de ne pas conserver la page produite (par exemple parce qu’elle contient du code en PHP qu’on veut faire tourner à chaque hit).

X-Varnish-Purge: *
Cet entête indique à Varnish tout purger ; il est émis par la fonction suivre_invalideur(), à chaque modification des données. Il est également émis lorsqu’un changement de date provoque la publication d’un « article post-daté ».

De plus Varnish pourra aussi, indépendamment des entêtes envoyés par l’application, se baser sur l’URL pour invalider certaines pages.

Ainsi :

l’URL …?var_mode=calcul est détectée par Varnish (indépendamment des entêtes de SPIP décrites ci-dessus), et invalide la page concernée (et celle-ci seulement).
l’URL …?var_mode=(recalcul|images) est détectée par Varnish et invalide tout le cache de Varnish (notamment, parce qu’un recalcul d’une page peut provoquer la modification d’un fichier de CSS ou javascript associé).
l’URL de suppression du cache SPIP depuis l’espace privé (un clic sur le bouton dans ?exec=vider_cache) invalide aussi tout le cache Varnish.

Implémentation

Cette approche me semble au final plus simple que celle donnée par la doc de Varnish, qui passe par la définition d’une méthode HTTP non standard PURGE. Pour l’implémenter, j’ai construit un fichier de configuration pour Varnish, ainsi qu’un plugin pour SPIP.

Remarque : les deux éléments (configuration et plugin) sont conçus pour fonctionner de concert, mais il est tout à fait possible d’utiliser la configuration pour Varnish sans installer le plugin SPIP. Les pages « dynamiques » produites par SPIP ne seront alors pas enregistrées dans le cache de Varnish, qui y stockera néanmoins tous les fichiers statiques (images, javascript, CSS etc.) selon des règles « assez bonnes ».

Autrement dit, sur un serveur hébergeant plusieurs sites, on peut installer Varnish sans installer le plugin sur tous les sites : seuls les sites SPIP ayant installé le plugin en tireront le maximum, mais les autres ne seront pas pénalisés.

Télécharger le plugin

La configuration de Varnish et le plugin SPIP sont téléchargeables depuis SPIP-Zone : http://zone.spip.org/trac/spip-zone/browser/_plugins_/varnish

Le plugin nécessite l’usage du plugin StatsJS, car, dès lors qu’on demande à Varnish de servir directement les pages SPIP, celui-ci ne peut plus comptabiliser les visites des pages de la façon habituelle.

Configuration de Varnish

Voici le fichier de configuration, commentaires inclus :

# 
# Configuration de varnish (varnish-cache.org)
# optimisée pour SPIP
# 
# Varnish est un proxy inverse, installé sur le serveur Web,
# qui permet :
#
# - 1. Rapidité. Absorbe une demande importante sur une même URL
#      et y répond directement sans solliciter apache
# - 2. Tolérance aux pannes. Renvoie des pages depuis sa mémoire cache
#      même lorsque apache est planté
# - 3. Souplesse dans l'affectation de serveur(s) apache à différentes
#      applications (par ex. load balancing, changement de serveur, etc)
# - 4. Moindre consommation de CPU : économique et écologique
# 
# La configuration ci-dessous permet d'optimiser son fonctionnement
# avec SPIP ; elle s'applique sans problème à des serveurs
# hébergeant aussi d'autres types de scripts, qui peuvent utiliser
# les mêmes mécanismes de communication X-Varnish-Message et X-Varnish-Purge
#


## -- BACKEND PRINCIPAL --
##
## Tout d'abord, nous allons définir l'adresse du serveur apache hébergeant
## nos sites Web (ce que varnish appelle le backend).
##
## Dans notre cas, le serveur apache est accessible sur le
## port 8080 de l'interface 127.0.0.1 ; il répond aux mêmes requêtes que
## lorsqu'il est configuré sur le port 80 :
##     GET / HTTP/1.0
##     Host: nomdusite.tld
##
## Pour ce backend, nous définissons un temps de latence avant le premier octet
## de 300s ; ainsi, lorsqu'une page demande un temps de calcul très long (par
## exemple un POST d'un long article), on attend jusqu'à 5 minutes avant de
## déclarer forfait et d'envoyer une erreur 500.
## http://vincentfretin.ecreall.com/articles/varnish-guru-meditation-on-timeout
##
## De plus, varnish va lancer chaque seconde une requête de test sur une URL
## type ; si 2 requêtes sur les 3 dernières sont en faute, il déclarera le
## backend "malade" ("sick") et passera en mode "tolérance aux pannes",
## jusqu'à ce que le backend revienne en bonne santé ("healthy").
##
backend default {
	.host = "127.0.0.1";
	.port = "80";
	.first_byte_timeout = 300s;
	.probe = {
		# Ici mettre un hit vers un petit fichier fixe sur le backend 
		#.url = "/";
		.request =
			"GET /prive/images/searching.gif HTTP/1.0"
			"Host: zzz.rezo.net"
			"Connection: close";
		.timeout = 34 ms; 
		.interval = 3s; 
		.window = 3;
		.threshold = 2;
	}
}


## -- BACKEND DE TEST D'ERREUR 503 --
##
## Ce backend "guru" est toujours en panne ; il est destiné à provoquer
## une erreur 503, ce qui permet d'afficher délibérément le message d'erreur
## qu'on définira en fin de ce fichier de configuration
## => http://nomdusite.tld/I'm-a-guru
##
backend guru {
	.host = "127.0.0.1";
	.port = "8082"; # !!il faut choisir un numéro de port inutilisé
}



## -- RECV --
## Cette fonction est appelée à chaque connexion d'un client sur varnish.
##
## Elle normalise la requête :
## - en supprimant les cookies inutiles
## - en unifiant les différents types de Accept-Encoding
##
sub vcl_recv {

	## -- GRACE --
	##
	## La "grace" sert dans deux scénarios :
	##
	## - a. "Absorber" la connexion *simultanée* de plusieurs clients
	##      sur une même URL : le temps que le backend calcule et renvoie
	##      la nouvelle réponse, on s'autorise à servir une réponse en cache
	##      mais dont la date de péremption est dépassée de moins de 30s.
	## - b. "Panne" : si le backend est en panne, on s'autorise à servir
	##      des contenus mis en cache mais dont la date de péremption est
	##      dépassée (jusqu'à une heure).
	##
	if (req.backend.healthy) {
		set req.grace = 30s;
	} else {
		set req.grace = 1h;
	}


	## -- COOKIES --
	##
	## On nettoie ici les cookies qui n'impactent pas SPIP ;
	## essentiellement les cookies de tracking statistique, mais aussi
	## les cookies d’options traitées côté client (vs. côté serveur).
	## Attention les cookies importants côté serveur (cookie de session admin, 
	## par exemple) ne doivent *pas* être nettoyés.
	##
	if (req.http.Cookie) {

		## __utm[a-z] = cookies google analytics
		## xtvrn = cookies xiti
		set req.http.Cookie = regsuball(req.http.Cookie, "(^|; ) *(__utm[a-z]|xtvrn)=[^;]+;? *", "\1");

		## _pk.* = cookies piwik
		##   => attention, sur l'URL de piwik, ne pas nettoyer les cookies piwik
		if (req.url !~ "/piwik\.php") {
			set req.http.Cookie = regsuball(req.http.Cookie, "(^|; ) *(_pk_[^=]+)=[^;]+;? *", "\1");
		}

		## dans une application particulière, le cookie "blink" est traité
		## côté client ; il ne nous intéresse pas, on le nettoie
		set req.http.Cookie = regsuball(req.http.Cookie, "(^|; ) *(blink)=[^;]+;? *", "\1");

		## si le cookie résultant est vide, le supprimer
		if (req.http.Cookie == "") {
			remove req.http.Cookie;
		}

		## si on est dans un repertoire statique ignorer totalement
		## les cookies (ici, les répertoires SPIP & Drupal + les images
		## css, scripts, etc.)
		## (le ?\d+ final est un éventuel timestamp)
		if (req.url ~ "^[^?]*\.(css|js|jpg|jpeg|gif|png|ico|txt|mp3)(\?\d+)?$"
		|| req.url ~ "^/(local|IMG|extensions|plugins|static)/") {
			remove req.http.Cookie;
		}

	}
	## fin de la section COOKIE


	## -- X-FORWARDED-FOR --
	##
	## Ajouter un entête X-Forwarded-For: IP
	## en le concaténant avec un éventuel entête déjà existant
	##
	if (req.http.x-forwarded-for) {
		set req.http.X-Forwarded-For = req.http.X-Forwarded-For ", " client.ip;
	} else {
		set req.http.X-Forwarded-For = client.ip;
	}

	## -- GZIP --
	## unifier les accept-encoding: accepte gzip ou pas ; on ne gere pas deflate
	## (notamment : FF annonce "gzip, deflate" et Safari "gzip,deflate" !)
	if (req.http.Accept-Encoding) {
		if (req.http.Accept-Encoding ~ "gzip") {
			set req.http.Accept-Encoding = "gzip";
		#} elsif (req.http.Accept-Encoding ~ "deflate") {
		#	set req.http.Accept-Encoding = "deflate";
		} else {
			remove req.http.Accept-Encoding;
		}
	}

	## -- RANGE --
	## Varnish ne doit pas gérer pas les requêtes de contenu partiel ;
	## on les passe directement au backend
	## cf. http://forum.developers.facebook.net/viewtopic.php?id=68440#p253346
	if (req.http.Range) {
		return(pipe);
	}

	## -- TEST 503 --
	## cf. ci-dessus le backend "guru" qui ne mène nulle part
	## se teste via le navigateur sur http://urldusite.tld/_-_-I-m-a-guru
	## permet d'afficher l'erreur définie en bas de ce fichier
	## le nom zen vient de l'erreur par défaut de Varnish : "guru meditation"
	if (req.url == "/_-_-I-m-a-guru") {
		set req.backend = guru;
	}


	## -- DIVERS --
	## certain robot fou demande host:127.0.0.1, on le jette immédiatement
	if (req.http.host == "127.0.0.1") {
		error 500 "Unknown virtual host.";
	}
}


## -- FETCH --
## Cette fonction est appelée à chaque retour du backend vers varnish.
##

sub vcl_fetch {

	## -- REDIRECTION --
	## supprimer le port (:8080) envoyé par le backend lors d'une redirection
	## car on veut rediriger vers le port public :80
	if (beresp.http.Location) {
		set beresp.http.Location = regsub(beresp.http.Location, "^(\w+://[^/]+):\d+", "\1");
	}

	## -- TTL: DUREE DE CACHE --
	##
	## C'est la durée de vie de la page dans le cache ; au-delà de cette durée,
	## elle ne pourra être servie au client que dans le scénario de "grace".
	##
	## Différents cas :
	## -1 la ressource signale X-Varnish-TTL: 20s
	##    (c'est ce que fait le plugin pour SPIP)
	##    elle annonce à varnish que son script lui signalera plus tard,
	##    par un entete X-Varnish-Purge, quand le moment sera venu de
	##    rafraichir la page. Dans ce cas de figure on peut donc la mettre
	##    en cache pour la durée indiquée (si elle est > 0)
	## -2a la ressource est statique, on la cache un certain temps raisonnable
	##     (sauf si un autre entete indique qu'elle n'est pas cacheable)
	## -2b la ressource est dynamique, on ne la cache pas

	## L'entête X-VARNISH-TTL permet au backend de définir le ttl du cache
	## code inspiré de: http://open.blogs.nytimes.com/2010/09/15/using-varnish-so-news-doesnt-break-your-server/
	## http://www.lovelysystems.com/configuring-varnish-to-use-custom-http-headers/
	##
	## (n'utilise pas X-SPIP-Cache car, sur SPIP standard, ça tuerait les stats)
	##
	if (beresp.http.X-VARNISH-TTL) {
		C{
			char *ttl;
			ttl = VRT_GetHdr(sp, HDR_BERESP, "\016X-VARNISH-TTL:");
			VRT_l_beresp_ttl(sp, atoi(ttl));
		}C
		remove beresp.http.X-VARNISH-TTL;
	}
	## sinon se baser sur la logique habituelle de varnish (Expires, etc) ;
	## en ajoutant une règle pour les fichiers dont on sait avec certitude
	## qu'ils sont statiques : les images etc
	else {
		## ne cacher que les css, js, jpg, gif, png, etc.
		## le (?\d+) est un éventuel timestamp
		## à noter : si apache est bien configuré, cette ligne est inutile
		if (req.url ~ "\.(css|js|jpg|jpeg|gif|png|ico|txt|mp3)(\?\d+)?$"
		|| req.url ~ "^/(local|IMG|extensions|plugins|static)/") {
			set beresp.ttl = 600s;
			set beresp.http.Cache-Control = "max-age=600";
			set beresp.http.Vary = "Accept-Encoding";
		}
		## ne pas cacher une ressource qui ne precise pas d'entete de cache
		else {
			if (
			(!beresp.http.Cache-Control && !beresp.http.Expires)
			|| beresp.http.Cache-Control ~ "no-cache"
			|| beresp.http.Cache-Control ~ "private" ) {
				set beresp.cacheable = false;
			}
			#else {
			#	set beresp.cacheable = false;
			#	remove beresp.http.Cache-Control;
			#}
		}
	}
	## ne pas conserver une ressource servie vieille aux robots
	if (beresp.http.X-Varnish-Stale) {
		set beresp.cacheable = false;
		#remove beresp.http.X-Varnish-Stale;
	}


	## -- INVALIDATIONS --
	##

	## On a vu ci-dessus qu'une page pouvait entrer en cache si elle s'annonçait
	## via X-Varnish-Message-OK
	##
	## Si à l'inverse le backend veut invalider le cache, il suffit
	## qu'il envoie un entête X-Varnish-Purge
	##
	if (beresp.http.X-Varnish-Purge) {
		purge("req.http.host == " req.http.host);
		remove beresp.http.X-Varnish-Purge;
		set beresp.cacheable = false;
	}


	## -- VAR_MODE --
	## Cette section gère les invalidations via le bouton d'admin
	## si on demande un var_mode=recalcul on va par principe tout purger
	## pour ne pas subir de cache secondaire, par exemple dans local/
	## lorsqu'on modifie des CSS ou des images calculées
	## En revanche un var_mode=calcul est plus léger
	if (req.url ~ "[?&]var_mode=(recalcul|images)") {
		purge ("req.http.host == " req.http.host);
		set beresp.cacheable = false;
	}
	## si on demande un var_mode=calcul on va purger uniquement la page
	## demandee, sans son var_mode
	elsif (req.url ~ "[?&]var_mode=calcul") {
		 purge ("req.http.host == " req.http.host " && req.url == " regsuball(req.url,"[&?]var_mode=.*$", ""));
		set beresp.cacheable = false;
	}

	## -- GRACE --
	## Si la réponse est cacheable, on peut la conserver pour un maximum d'1h
	## au cas où on aurait une panne (maximum des "grace" définies dans RECV)
	## http://varnish-cache.org/trac/wiki/VCLExampleGrace
	set beresp.grace = 1h;


	## -- RANGE --
	## seuls les gros fichiers (sons, videos) sont susceptibles de valoir
	## un range ; on n'annonce donc le range que pour ceux-la, et on desactive
	## l'entete
	if (beresp.http.Accept-Ranges && beresp.http.content-type !~ "(image|audio|video)/") {
		remove beresp.http.Accept-Ranges;
	}

	## -- ETAG --
	## corrige un bug d'apache qui donne le même Etag aux représentations
	## gzip et non-gzip d'un même fichier...
	if (beresp.http.content-encoding == "gzip"
	&& beresp.http.etag) {
		set beresp.http.Etag = regsub(beresp.http.etag, ".$", "-gzip\0");
	}

	## -- ACTION=CRON --
	## inutile de solliciter la page action=cron de SPIP plus d'1 fois par 5s
	## (à noter : avec les stats en js cette action disparaît)
	if (req.url ~ "\?action=cron$") {
		set beresp.ttl = 5s;
		set beresp.cacheable = true;
	}

}


## -- HASH --
##
## Cette fonction établit le nom du cache en fonction des caractéristiques
## de la requête
sub vcl_hash {
	set req.hash += req.url;
	if (req.http.host) {
		set req.hash += req.http.host;
	} else {
		set req.hash += server.ip;
	}
	return (hash);
}


## -- HIT --
##
## Cette fonction est appelée quand une page est trouvée dans le cache
## de Varnish ; on ajoute une logique pour que "force-reload", sur un
## navigateur correct, n'utilise pas le cache : il conduit jusqu'au backend
## et met à jour le cache
sub vcl_hit {
	# non cacheable, on passe
	if (!obj.cacheable) {
		return (pass);
	}

	# force-refresh will update the cache
	# http://www.varnish-cache.org/trac/wiki/VCLExampleEnableForceRefresh
	if (req.http.Cache-Control ~ "no-cache") {
		# Ignore requests via proxy caches, IE users and badly behaved crawlers
		# like msnbot that send no-cache with every request.
		if (! (req.http.Via || req.http.User-Agent ~ "bot|MSIE")) {
			set obj.ttl = 0s;
			return (restart);
		}
	}

	# standard response: use the cached version
	return (deliver);
}

## -- DELIVER --
##
## Cette fonction est appelée à l'envoi final du fichier, sauf (pass)
##
## On met le champ Age dans X-Varnish-Age sinon ça fait râler redbot.org
## On supprime Accept-Ranges de tous les fichiers sauf les images/sons/vidéos
##
sub vcl_deliver {
	{
		set resp.http.X-Varnish-Age = resp.http.age;
		remove resp.http.age;
		if (resp.http.content-type !~ "(image|audio|video)/") {
			remove resp.http.accept-ranges;
		}

	}
}

## -- ERROR --
##
## Cette fonction est appelée en cas d'erreur, par exemple
## lorsque l'objet n'est pas en cache et que le backend est
## en panne (erreur 503).
##
## On peut la déclencher volontairement, pour la tester, via l'URL "guru"
##

sub vcl_error {
    set obj.http.Content-Type = "text/html; charset=utf-8";
    synthetic {"
<html><head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<title>"} obj.status " " obj.response {"</title>
<style type="text/css"> 
body {
	background: #689ab3;
	color: #333;
	margin: 0;
	font-size:1.3em;
	font-family: georgia, serif;
}
 
div {
	margin: 30px 0 0 0;
	background: #ffffff;
	opacity: 0.6;
	width: 650px;
	padding: 20px 20px 23px 23px;
}
 
p {
	margin: 0.5em 0 0.5em 0;
}

p.en {
	margin: 0 0 0.5em 0;
}

p.fin {
	margin: 0.5em 0 0 0;
}
 
p.message {
	font-size: 1.5em;
	margin: 0 0 0.5em 0;
}	
 
h1 {
	font-size: 2em;
	margin: 0 0 0.5em 0;
	font-weight:normal;
	display:none;
}
 
 
</style> 
</head><body> 
 
<div> 
 
<p class="message">Le service est momentan&#233;ment indisponible.<br /> 
Veuillez r&#233;essayer un peu plus tard.
</p> 

<p class="en">The service is currently unavailable. Please try again later.
</p>
 
<p class="fin"><small>Erreur "} obj.status {" | XID: "} req.xid {"</small></p> 
 
</div> 


</body></html>
"};
    return (deliver);
}

Comme on le voit c’est un gros fichier… on pourra en suivre le développement dans le répertoire du plugin.

Dans le prochain article j’indiquerai comment procéder pour terminer l’installation.

14 Messages de forum

# Interfacer Varnish & SPIP Le 30 mars 2011 à 11:12 , par Beurt

Merci encore pour ces billets, à la fois très didactiques et pratiques !

Je suis hébergé dans un contexte où je ne contrôle pas la configuration de Varnish. Est-ce encore utile de manipuler les en-têtes des pages avec Spip (et le plugin que tu viens de mettre sur la zone) ?
- # Interfacer Varnish & SPIP Le 30 mars 2011 à 13:12 , par Fil
  
  Une configuration "par défaut" de Varnish respectera les entêtes de cache de SPIP, qui envoie toujours des pages « dynamiques » donc non cachables par le client. Or ce qu’on veut ici, c’est distinguer le cache client et le cache varnish.
  
  Si tu ne contrôles pas Varnish, tu peux imaginer envoyer une durée de cache > 0 sur les pages SPIP. Avec comme conséquence parfois un léger décalage entre ce que voit un utilisateur sans cookie par rapport à un utilisateur ayant un cookie. S’il s’agit de quelques secondes (10s ou 30s par exemple), ça peut être utile pour absorber des chocs violents.
  
  Mais ce n’est pas [en tous cas pas encore] l’objet de ce plugin, qui implémente un modèle de communication entre Varnish et l’application.
- # Interfacer Varnish & SPIP Le 30 mars 2011 à 17:34 , par Beurt
  
  OK, merci Fil.
  
  Donc ce n’est pas forcement très utile de « teeker » Spip si on est derrière un cache Varnish sur lequel on n’a pas la main...
  
  J’ai soumis ta série d’articles aux décideurs qui chapeautent la config du serveur qui m’héberge (ainsi que moult autres Spip), on va voir si tu les inspires ! :-)
- # Interfacer Varnish & SPIP Le 30 mars 2011 à 18:58 , par Fil
  
  Oui. Ce travail n’est pas exclusif à SPIP, il pourrait être adapté à d’autres logiciels sans grande difficulté. L’hébergeur a tout intérêt à regarder de près, car ça permet de servir beaucoup plus de clients avec moins de machines…
# Interfacer Varnish & SPIP Le 31 mars 2011 à 10:59 , par aymeric

Excellent article ! Je cherchait des infos sur Varnish (pour Wordpress) et le détail de cette config permet vraiment de mieux decrypter son fonctionnement.
Merci :-)
# Interfacer Varnish & SPIP Le 1er avril 2011 à 08:45 , par Cédric
Super ! Deux ou trois petites questions :
- les requêtes en POST sont elles automatiquement en mode by-pass ? je ne vois rien dans le fichier de configuration
- est-ce que tu prévois quelque chose pour être en by-pass quand tu as un cookie admin ? Ou est-ce que tu passe quand meme via le cache varnish ?
- comment gère tu l’accès à ecrire/ ? en by-pass ? via une url externe non varnishée ? avec une règle que je n’ai pas vue ?
Sinon pour action=cron, je pense que cette règle devient parasite plus qu’autre chose à partir du moment où on utilise job_queue : le hit sur cette url n’est envoyé que lorsqu’il y a effectivement de travail à faire, et le filtrer risque plus de perturber la gestion de file qu’autre chose, notamment en cas de spool massif à traiter.
- # Interfacer Varnish & SPIP Le 1er avril 2011 à 09:03 , par Fil
  
  La méthode POST et les cookies sont traités en PASS par défaut, ma config ne fait qu’éliminer les cookies "non significatifs", pour permettre de stocker les pages des visiteurs ayant par exemple un cookie de stats.
  
  En ce qui concerne la règle pour action=cron, elle est précisément destinée à de vieux sites SPIP qui n’ont pas installé ni job_queue ni statsjs. En effet s’ils ont statsjs, il n’y a plus du tout de action=cron ; et s’ils ont job_queue l’URL n’est pas souvent présente et le cache de 5s ne s’applique donc que très rarement.
# Interfacer Varnish & SPIP Le 7 avril 2011 à 23:29 , par deor

Merci de partager ça.

Pour ma part, j’ai choisi nginx (pour tout ce qui est statique) devant Apache (pour la partie dynamique), je ne connaissais pas Varnish. De ce que j’ai pu lire un peu, nginx offre de meilleurs performances en reverse-proxy (puisqu’il ne fait pas que ça). En plus, nginx est vraiment simple d’utilisation (ça ressemble beaucoup à Apache, niveau conf).

Qu’est-ce qu’il y a d’intéressant dans Varnish par rapport à nginx ?
- # Interfacer Varnish & SPIP Le 8 avril 2011 à 09:04 , par Fil
  
  Comme tu dis, nginx est un serveur complet, qui peut remplacer totalement apache et servir directement les pages PHP. (Mais à ce compte-là, Apache aussi peut faire office de proxy.) L’avantage de Varnish c’est qu’il est optimisé pour jouer son rôle le plus rapidement possible et en évitant tout chargement inutile en mémoire (même la configuration est écrite en pseudo-C et est compilée avant exécution). Pour savoir ce que ça a comme conséquences pratiques en termes de micro-secondes gagnées, il faudrait monter un benchmark.
# Interfacer Varnish & SPIP Le 22 janvier 2012 à 14:06 , par Dimitri

Hello,

i installed varnish on my server and the plugin inside spip. When i started varnish, i did it using the file /etc/varnish/default.vcl

Are you sure that the .vcl included in the plugin is executed ? If i try to start varnish using your .vcl i get an error.

I don’t understand if everithing is running well or if i have to do something more, just like insert something in the squellettes.

I hope you will reply me, thanks for you work BTW.
- # Interfacer Varnish & SPIP Le 22 janvier 2012 à 14:29 , par Fil
  
  it works here !
  
  what is your error ? what version of varnish ?
- # Interfacer Varnish & SPIP Le 23 janvier 2012 à 10:13 , par Dimitri
  
  Varnish 3.0. It tells me that there is an error at line 143 (if i remember). So, you confirm me that i have to start varnish from ssh whit your vcl file and not whit the standard one. Right ?
- # Interfacer Varnish & SPIP Le 23 janvier 2012 à 10:21 , par Fil
  
  This config file is for Varnish 2. I have yet to modify it for Varnish 3, as they have changed the syntax (and they seem to plan to change it again for Varnish 4).
- # Interfacer Varnish & SPIP Le 23 janvier 2012 à 12:39 , par Dimitri
  
  Ok ! I hope to find the new configuration file soon ! Thanks in advantage for your support ;)

Interfacer Varnish & SPIP

Principe de communication

Implémentation

Télécharger le plugin

Configuration de Varnish

14 Messages de forum

Rubriques

Dans la même rubrique

Mots-clés