Booster votre blog WordPress avec Varnish

Date: 12/10/2010 | Catégories: Open-source,Planet-libre,Web | Tags: ,,,

Varnish est un accélérateur de sites Web fonctionnant sur le principe d'un reverse proxy. Varnish va prendre en charge les requêtes HTTP venant de vos visiteurs et communiquer avec votre serveur Web en ne demandant la création des pages Web seulement quand cela est nécessaire.

C'est un projet open-source sous licence FreeBSD.

Installation

Sur un Ubuntu Server (ou une distribution Debian "like"), l'installation se résume à la commande suivante. Vous aurez ainsi la version standard maintenu par les dépôts:

sudo aptitude install varnish

Pour disposer d'une version plus récente et seulement sous Ubuntu, vous pouvez utiliser les lignes de commande suivantes:

curl http://repo.varnish-cache.org/debian/GPG-key.txt | sudo apt-key add -

sudo echo "deb http://repo.varnish-cache.org/ubuntu/ $(lsb_release -s -c) varnish-2.1" >> /etc/apt/sources.list

sudo aptitude update

sudo aptitude  install varnish

Nous allons donc dans un premier temps tester Varnish sur la configuration initiale de notre serveur Web (qui comprend dans mon exemple deux sites virtuels sous Apache). Cette configuration de test permettra de tester les performances de Varnish sans aucun impact sur vos sites (les visiteurs continueront à passer directement par votre serveur Web Apache). Enfin, si les tests sont concluants, nous modifierons la configuration finale pour que vos visiteurs transitent de manière transparente par Varnish.

Configuration de test

Varnish appelle backend les serveurs Web qu'il doit accélérer. Il est possible de définir un ou plusieurs backends par serveur Varnish.

Ainsi, si l'on souhaite accélérer le site http://blog.nicolargo.com qui est hébérgé sur un serveur, il faut saisir la configuration suivante dans le fichier /etc/varnish/default.vcl (configuration librement inspiré de la documentation officielle sur comment optimiser son blog WordPress avec Varnish) avec une gestion du cache sur les requête POST, pas de cache pour la zone admin, gestion des cookies de Google Analytics.

Vous pouvez télécharger la configuration Varnish VCL complète pour WordPress ici.

Le port d'écoute par défaut de Varnish est  TCP/6081 (défini dans le fichier /etc/default/varnish).

Si vous avez un Firewall (iptables) sur votre serveur, il faut penser à ajouter la règle suivante:

iptables -A OUTPUT -p tcp --dport 6081 -j ACCEPT

On relance Varnish pour prendre en compte la configuration:

sudo service varnish restart

Si tout marche bien, vos sites doivent s'afficher avec les URL: http://www.nicolargo.com:6081 et http://blog.nicolargo.com:6081 (à remplacer par vos sites hein, faite pas les boulets...).

Tests sur le site statique

Test local sur le site statique (avec uniquement des éléments statiques page HTML & images). La configuration donnée ci-dessous ne montre pas l'optimisation pour ce site.

Test sur une page statique (HTML simple) sans Varnish:

ab -t 30 -c 5 http://www.nicolargo.com/

Requests per second:    651 [#/sec] (mean)

Time per request:       7.6 [ms] (mean)

Test sur une page statique (HTML simple) avec Varnish:

ab -t 30 -c 5 http://www.nicolargo.com:6081/

Requests per second:    652 [#/sec] (mean)

Time per request:       7.6 [ms] (mean)

Sur notre site Web statique, on n'a donc pas de gain au niveau de la capacité maximale de montée en charge du serveur Apache (Requests per second). Ce qui est normal vu qu'Apache n'a pas grand chose à faire pour servir ce genre de page. Par contre on observe une occupation mémoire moindre pendant le test avec Varnish (environ 10% de moins).

Tests sur le site dynamique (WordPress)

Test en local sur le site Web dynamique (WordPress, déjà optimisé en suivant ce tutoriel).

Test sur la page index d'un blog WordPress sans Varnish:

ab -t 30 -c 5 http://blog.nicolargo.com/

Requests per second:    588 [#/sec] (mean)

Time per request:       8.5 [ms] (mean)

Test sur la page index d'un blog WordPress avec Varnish:

ab -t 30 -c 5 http://blog.nicolargo.com:6081/

Requests per second:    3460 [#/sec] (mean)

Time per request:       1.5 [ms] (mean)

Sur notre site dynamique, la valeur ajoutée de Varnish est importante car on a ici un gain de plus de 488% en terme de nombre de requêtes simultanées que votre serveur peut fournir. Sur une page dynamique un peu plus lourde (par exemple un billet avec beaucoup de commentaires), le gain peut alors monter jusqu'à 650%.

Attention, cela ne veut pas dire que votre blog va s'afficher 488% plus vite avec Varnish mais "seulement" que votre serveur pourra accepter 488% de requêtes simultanées maximales en plus.

Configuration finale

Une fois votre site accéléré validé, il faut passer Varnish en production. Les actions suivantes sont à effectuer.

Configurer le serveur Apache hébergeant votre blog pour écouter sur un port différent du port TCP/80 (par exemple TCP/8080). Sous Ubuntu Server, on commence par modifier le fichier /etc/apache2/ports.conf pour lui demander d'écouter les requêtes HTTP sur le port 8080 en lieu et place du port 80:

NameVirtualHost *:8080

Listen 8080

On modifie ensuite le fichier de configuration de nos sites /etc/apache2/site-enabled/virtualhosts: (notez bien la modification du port :8080 et l'utilisation du format de log varnishcombined)

# WWW

<VirtualHost *:8080>

DocumentRoot /var/www/www

ServerName nicolargo.com

ServerAlias www.nicolargo.com

ServerAdmin contact@pasdespam.com

CustomLog /var/log/apache2/www-access.log varnishcombined

ErrorLog /var/log/apache2/www-error.log

</VirtualHost>

# BLOG

<VirtualHost *:8080>

DocumentRoot /var/www/blog

ServerName blog.nicolargo.com

ServerAdmin contact@pasdespam.com

CustomLog /var/log/apache2/blog-access.log varnishcombined

ErrorLog /var/log/apache2/blog-error.log

</VirtualHost>

On configurer le serveur Apache pour loguer les adresses sources et non pas l'adresse du serveur Varnish. Il suffit pour cela d'ajouter la ligne suivante dans le fichier /etc/apache2/apache2.conf:

LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" varnishcombined

La configuration d'Apache est maintenant fini, il faut alors configurer Varnish pour écouter sur le port TCP/80 et changer la configuration du "backend" en éditant la section suivante du fichier /etc/default/varnish:

DAEMON_OPTS="-a :80 \

-T localhost:6082 \

-f /etc/varnish/default.vcl \

-S /etc/varnish/secret \

-p thread_pool_add_delay=2 \

-p thread_pools=4 \

-p thread_pool_min=200 \

-p thread_pool_max=4000 \

-p cli_timeout=25 \

-p session_linger=100 \

-s file,/var/lib/varnish/$INSTANCE/varnish_storage.bin,1G"

On change ensuite la configuration de Varnish pour pointer les backends vers le port 8080:

backend blog {

.host = "blog.nicolargo.com";

.port = "8080";

}

La dernière chose à faire si votre serveur est protégé par un Firewall IpTables est de modifier la règle ajoutée dans le premier chapitre de ce billet et d'y ajouter une nouvelle règle pour une éventuelle administration locale de Varnish à l'aide de l'utilitaire varnishadm:

iptables -A OUTPUT -p tcp --dport 8080 -j ACCEPT

iptables -A OUTPUT -p tcp --dport 6082 -s 127.0.0.1 -j ACCEPT

On prend en compte la configuration finale en relancant les deux processus (Apache et Varnish):

sudo service apache2 restart

sudo service varnish restart

A partir de ce moment là, toutes les requêtes HTTP de vos visiteurs seront d'abord prise en compte par Varnish (sur le port TCP/80) puis ensuite, si nécessaire, par votre serveur Apache (TCP/8080).

Ecrire les logs sur le disque

Update du 22/02/2012

Par défaut, Varnish n'écrit pas les logs dans un fichier. Pour forcer Varnish à générer des fichiers de logs au format NSCA dans le sous répertoire /var/log/varnishnsca, nous allons utiliser le daemon VarnishNSCA (installé en même temps que Varnish). Il faut commencer par vérifier que script de lancement du daemon VarnishNSCA (/etc/init.d/varnishnsca) ne contient pas un bug, comme c'est le cas dans ma version 3.0.2:

Remplacer la ligne suivante dans le fichier /etc/init.d/varnishnsca:

DAEMON_OPTS="-a -w ${LOGFILE} -D -P $PIDFILE}"

par

DAEMON_OPTS="-a -w ${LOGFILE} -D -P ${PIDFILE}"

Puis forcer le lancement du daemon en modifiant le fichier /etc/default/varnishnsca:

VARNISHNCSA_ENABLED=1

On peut ensuite lancer le daemon:

sudo service varnishnsca start

Il est alors possible d'analyser ce fichier avec vos outils de stats favoris. Par exemple en ligne de commande avec GoAccess:

goaccess -f /var/log/varnish/varnishncsa.log

Quelques commandes utiles

  • varnishlog: Affichage du log du daemon Varnish.
  • varnishstat: Affichage des statistiques d'utilisation de Varnish.
  • varnishhist: Affiche un historique sous forme de graphe des requêtes faites à votre serveur Varnish.
  • varnishadm: une interface d'administration locale de Varnish

Vous pouvez également consulter la documentation en ligne à l'adresse suivante.

  • Pingback: wp-popular.com » Blog Archive » Booster votre blog WordPress avec Varnish()

  • Peut être une piste pour le problème des cookies de WordPress: http://kristianlyng.wordpress.com/2010/08/13/stripping-cookies-with-vcl/

  • Salut,
    chouette article, bien détaillé ! 🙂

    Juste une petite précision : pour la mise en prod, il faut modifier le port du backend dans le fichier de config Varnish pour indiquer le port 8080 d’Apache.

    backend www {
    .host = « www.nicolargo.com »;
    .port = « 8080 »;
    }

    En lisant l’article, c’est pas évident au premier coup d’oeil… 😉

    Merci en tout cas !

  • @Romain: exact ! boulette de ma part, je modifie le billet !

  • rekcah

    Salut,

    une amélioration peut etre fait ici:
    if (req.http.host ~ « (www\.nicolargo\.com|nicolargo\.com) »)

    par:

    if (req.http.host ~ « ^(www\.)?nicolargo\.com$ »)

    sinon c’est très cool Varnish, deja 2 ans que je l’utilise et le VLC c’est génial, en plus avec l’inclusion de code C direct dans la conf c’est trop flexible.

  • Pingback: Nouveau serveur pour woueb.net « wOueb by Romain DECKER / Another IT Guy Blog()

  • j’ai mis ça y a un mois sur nos serveurs et qu’est-ce que c’est bon 🙂

    Load average divisé par deux, charge apache idem…

  • Sur la règle du pare-feu dans le cadre du test, tu t’es trompé, me semble-t-il.

    Elle est en INPUT au lieu d’être en OUTPUT

  • Pingback: Nginx+Apache ou Varnish+Apache ? Comparatif des fichiers de configuration | AbriCoCotier.fr()

  • Comme Gonzague je confirme Varnish ça déboite du steak 🙂 Il explose tous les reverse proxy existants (lighttpd, nginx & co.)

    Merci Nico pour ce tuto car ils ne courent pas les rues sur le web.

  • Bonjour Nicolas,

    les résultats sur le site en version statique m’interpellent, normalement tu devrais avoir un résultat beaucoup plus important que ça au niveau de Varnish. Peut-être un soucis de headers HTTP ou de configuration ?

    Cordialement,

  • @Jérôme Renard: la page en question (http://www.nicolargo.com) est assez lourde avec notamment une image de fond de 130Ko. Ceci explique peut être cela…

  • Sylvain

    Tiens, bizarre, au moment du changement de port dans /etc/default/varnish, si je change tout et passe avec la config que tu explique, il me retourne une tonne d’erreurs :

    /usr/sbin/varnishd: invalid option — S

    puis des erreurs dans le vcl …

    tu as rencontré ce problème ?

    en changeant juste le port de la config par défaut, ça marche par contre …

  • Sylvain

    J’en oublie ma politesse, désolé :

    Bonjour, et merci pour ton superbe billet 🙂

  • @Sylvain: Bonsoir ! Peux être un pb de version. Tu utilises quelle version de Varnish ? L’option -S est pourtant active depuis pas mal de temps…

  • Sylvain

    effectivement, je viens de me faire la reflexion à l’instant, c’est la v1.2 qui est dans les repo stable de debian 5 … je viens de passer en 2.1, c’est beaucoup mieux 🙂

  • Sylvain

    Salut Nico,

    Tu me confirme que du coup, tu cache 1G sur le disque ?

    c’est renseigné là :
    -s file,/var/lib/varnish/$INSTANCE/varnish_storage.bin,1G »

    Une idée de comment le passer en mémoire ? j’ai lu une commande qui remplace le 1G par 50% lui indiquant d’utiliser 50% en mémoire.

    Une idée la dessus ?

    Bonne soirée.

    S.

    • C’est exact, dans cette config, Varnish va utiliser un cache disque de 1Go contenu dans le répertoire /var/lib/varnish/$INSTANCE/.
      Pour l’utilisation d’un cache mémoire, tu peux tjrs configurer ce répertoire dans un tmpfs, mais tu vas perdre le contenu à chaque reboot de ta machine.
      J’ai lu qq part sur le site de Varnish qu’ils sont en train de prévoir une intégration avec Memchached… à suivre donc…

  • Nikkau

    « -s malloc,1G » pour cacher en mémoire.

    Btw, quit à vouloir optimiser, pourquoi ne pas virer Apache, qui a une gestion de la RAM dégueulasse, au profit d’Nginx et demander à Varnish de cacher en RAM?

    Ok on perd le cache à chaque restart mais a priori ça n’arrive que très rarement et une requête qui cache miss ne prend pas des heures pour autant.

  • Salut Nicolas,

    Suite à ton conseil, j’ai installé Varnish, et effectivement, ça déboite. Merci beaucoup. En lisant les commentaires, je me pose une question : Je suis resté en cache disque pour le moment, mais l’idée de passer en cache RAM ne serait pas pour me déplaire.

    Néanmoins, mes serveurs n’ont que 1,7 Go de RAM, et il faut que je garde un peu de place pour Apache et MySQL. Si je met moins de 1 Go de cache pour Varnish, est-ce que ça va beaucoup gêner ses performances ? Comment déterminer la bonne répartition de la RAM entre les différents process ?

    • Le calcul de la taille du cache est directement relié à ton type de site et au profil de trafic. 1go est un valeur par défaut pour un site avec un trafic important.
      Tu peux essayer avec un cache de 512mo et voir si le gain est plus important que sans cache RAM de 1go.
      Je suis intéressé par ton retour d’expérience sur le sujet.

      • avec un malloc mémoire de 16 ou 32M sur un tout petit VPS (256Mo de RAM), ça le fait bien 🙂

        un cache un Go, faut avoir envie (et l’utilité) de tout mettre en cache…

        à adapter au site web cible, à la config de la machine qui le fait tourner, etc. comme tu le disais précédemment NicoLargo.

  • Ryuke

    Bonjour !

    Merci pour ce ticket qui correspond exactement à ce que je cherchais pour configurer Varnish.
    J’ai néanmoins un petit soucis lors des tests. J’ai configuré deux backend différents et saisis la configuration suivante :

    director lb random {
    .retries = 5;
    { .backend = srv1; .weight = 7; }
    { .backend = srv2; .weight = 7; }
    }

    sub vcl_recv {
    set req.backend = lb;
    }

    Je lance les tests de benchmark : sur le port 80, j’ai un retour … sur le port Varnish, par défaut le 6081, j’ai l’erreur « apr_socket_recv: Connection refused (111) ». Les ports du firewall sont bien ouverts.

    Avez-vous une idée sur le problème ?

    Merci par avance.

    • Peux tu nous envoyer une copie (via pastebin.com) de ta configuration de Varnish et de tes règles IpTables ?

  • Erwan

    Bonjour Nico,
    Merci pour ce tuto sympa.
    J’ai une question à te poser en fait, à toi ou aux autres lecteurs.
    J’ai configuré mon Varnish avec 2 serveurs load balancé Apache derrière en local. J’ai aussi configuré un serveur DNS qui redirige les requêtes à destination des site web hebergés sur mes serveurs apache vers le serveur Varnish.
    Je suis un peu novice avec tout ça, et en fait dans la déclaration de mes backend je suis contraint de saisir l’adresse IPv4 de mes serveurs Apache et nom un nom de domaine. Ce n’est pas très scalable, j’aimerai pouvoir mettre un nom à la place.
    Je sais pas si je suis clair, je pourrai éventuellement éditer mon fichier /etc/hosts mais y a -til une autre solution ?
    Merci par avance !

  • s malloc,1G pour cacher en mémoire.

  • Bonjour Nico,

    merci pour ce tuto, je ne connaissais pas Vanish et effectivement cela speed. Du coup j’ai réfléchi à un truc :

    Si on a un peu de ram, ne pourrais ton pas, en plus de vanish, mettre le blog wordpress dans la ram via tmpfs ?

    Mon blog (wp-admin wp-content wp-includes, plugins et template compris fait 100 Mo).

    On crée un petit batch : au lancement de la bécane, tout ca en ram. En coupant la bécane retransféré sur le disque.

    On risque à mon avis rien, ce qui fait le blog c’est la base mysql qui change en fonction des commentaires et des articles.

    On aurait ainsi les images, le template qui se chargerait à une vitesse optimale, sans compter que si ca marche avec wp super cache, les pages php transformées par wp super cache en statistiques iront aussi à pleine vitesse…

    Tu en penses quoi ?

    • Bonjour Benoist,

      ton idée est intéressante mais je ne pense pas que tu es un réel gain par rapport à l’utilisation d’un reverse proxy RAM comme Varnish. En effet, dans le cas d’un blog WordPress, Varnish va s’occuper de cacher en RAM tous les fichiers statiques (images, vidéos…) et également les pages HTML générés par WordPress. C’est cette génération de page (interrogation de la BD MySQL, exécution des scripts PHP) qui prends du temps et le fait de mettre en tmpfs tout le contenu du blog ne changera pas grand chose.

      De plus il y a la problématique de la gestion des mises à jour de ton blog. En effet, quand tu vas écrire un nouveau billet contenant des images, ces dernières vont être stocké dans le répertoire uploads de ton répertoire WordPress en tmpfs. Sans une synchronisation avec ton disque dur, les données seront perdu en cas de redémarrage ou crash de ton serveur… Il faut donc au préalable avoir un script qui tourne en tache de fond et qui synchronise ton tmpfs et ton disque dur.

      Tu ne risques rien à faire un test. Je serais intéressé par une comparaison de résultat avec Varnish.

      • Bonjour NicoLargo,

        merci pour ta réponse. Effectivement, je vais tester et te tenir au courant (week-end prochain). J’ai déjà prévu la synchronisation toutes les xx minutes qui retransfère le répertoire upload sur le disque. Ca c’est fait 🙂

        Effectivement avec tes remarques complémentaires, je ne suis pas sur que le gain soit flagrant mais cela vaut le coup d’essayer.

  • Salut nico,
    tu as trouvé une syntaxe ok pour les cookies de commentaire ?
    a part la solution « pas de cache pour les identifiés » ?
    Merci

    • Je n’ai pas essayé de creuser mais du tu trouves une solution à ce problème je suis preneur.

    • J’ai trouvé une configuration de Varnish qui fonctionne aux petits oignons avec WordPress.

      Je modifie le billet tout de suite.

      Source: http://www.mihaivalentin.com/varnish-configuration-for-wordpress/

      • Cool ! merci pour le lien je vais regarder ca…

        • Tu peux aussi regarder directement la conf de mon billet que j’ai modifié et adapté…

          • Désolé j’avais pas vu la mise a jour (il faudrait peut être l’indiqué pour les « habitués » qu’il y a eu une mise a jour ?

            Bon sinon pour les cookies « commentaire » j’ai une idée qu’il faut que j’approfondisse avec les esi include…
            Si ca mache, je poste ma solution 😉

          • Le problème des commentaires semble résolu avec ma dernière configuration. Tu peux tester chez toi et me dire si cela marche aussi ?

          • Non ca ne marche que si tu as le cookie « wordpress_logged_in », si tu as un membre « classique » il doit retaper ses infos a chaque fois…

          • Mince… c’est dingue qu’il n’y est pas une solution simple pour résoudre ce problème…

  • Merci,

    Très bon tuto, on peut rajouter les éléments suivants afin de ne pas donner trop d’infos dans les en-têtes (pour des raisons de sécurité):

    sub vcl_deliver {
    #on supprime certaines en-têtes
    remove resp.http.Via;
    remove resp.http.X-Varnish;
    remove resp.http.Server;
    remove resp.http.X-Powered-By;
    #Pour ceux qui ont modepagespeed
    remove resp.http.X-Mod-Pagespeed;
    return (deliver);
    }

    a+

    Aymeric

  • Bonjour,

    juste pour signaler que j’ai forké le plugins wp-varnish dont les développements étaient gelés, mon fork est encore en version beta mais les purges pour tout le core de WordPress sont implémentée, ainsi qu’un support d’extension pour les purges spécifiques de plugins et de widgets (wptouch notamment)

    Je vous invite à me donner votre avis :
    https://github.com/ojdupuis/wp-varnish/blob/More_purge_orders/README.markdown

    Merci
    Olivier

  • Flo’

    Salut Nico,

    Je ne veux pas être méchante mais ça sert à quoi de faire tout ça pour avoir au final des performances globales aussi moyennes ? 🙁

    J’ai lancé une analyse GTMetrix sur ton site: tu as un indice C, comme n’importe quel bloggeur qui n’aurait rien optimisé. Il y aurait plein de choses à optimiser avant de mettre Varnish en place, tu ne crois pas ?

    • Mon blog a effectivement un C quand tu testes la home page. Cette page ne represente que 1% de mon trafic. Pour un blog il est plus intéressant de tester l’affichage des billet ou j’obtient alors un B. Ce n’est pas encore parfait, je sais mais les optimisations restantes ne simplifient pas l’administration WordPress (par exemple la combinaison des JS nécessite des actions manuelles incompatibles avec le temps que je souhaite passer lors des mises à jours de mon site).

      Avant de mesurer il est bon de savoir ce que l’on cherche à mesurer…

  • Sylvain

    Flo,

    je te trouve assez critique, varnish n’est pas là que pour répondre a une belle analyse GTMetrics, ça a aussi pour but de délester un serveur de certaines charges, et meme pour ce qui concerne nico, j’imagine que l’idée est plus dans le test, et le partage d’une connaissance pas forcement hyper répendue.
    Perso ça m’a permis d’avoir une meilleur vision de base de varnish avant de creuser un peu plus, et rien que pour ça je remercie nico.

  • Flo’

    Oui, je comprends et j’ai d’ailleurs apprécié l’article mais je suis tout de même étonnée. A mon sens, mettre Varnish en place c’est intéressant dans une démarche d’optimisation globale.

  • bonjour à tous,

    j’essai de mettre en place varnish sur mon serveur apache pour tester dans un premier temps le gain. Après je pense l’utiliser sur mon serveur en prob Symfony.

    J’ai suivit a la lettre le tuto, mais je n’arrive pas a afficher ma page web sur le port 6081.
    Mon virtual host est configurer sur le port 80, es la source du probleme?

    merci

    • Finalement j’avais un probleme de firefwaal.
      Maintenant ma page
      http://silk.cube-concept.com:6081/ affiche:

      Error 503 Service Unavailable

      Error talking to backend

      Guru Meditation:

      XID: 180169212

      Varnish

  • Mat’

    Bonjour et merci pour ce tuto, hors peut on dire à Varnish de vider son cache une fois que la page PHP à été modifié et non pas à intervalle régulière, parce que je fais des test sur un forum et une fois qu’il y a un nouveau message il n’est pas affiché sur la page d’accueil car c’est la page en cache !!

    Cordialement

  • Pingback: Booster Apache avec Varnish! votre blog wordpress vous en remerciera | | Mémo outils linuxMémo outils linux()

  • Pingback: Les acteurs du Web en ont parlé [#16] | Le blog des nouvelles technologies : Web, Technologies, Développement, Interopérabilité()

  • Pingback: La veille du week-end (vingt-cinquième) | LoïcG()

  • Je viens de procéder à 2 install Varnish + WP.
    Sur 2 serveurs différents (1 CentOS, 1 Ubuntu server).
    Avec un Varnish 3.
    Et impossible de purger mes pages (home ou autres).
    Même en faisant des : curl -X PURGE -x http://127.0.0.1:6081 http://www.mondomaine.com/mapage
    Rien n’y fait …
    As-tu eu ce genre de souci ?

    • Non, tu n’as pas un pb d’ACL ?

      Perso, pour les purges je laisse faire le plugin WordPress suivant: http://wordpress.org/extend/plugins/varnish-http-purge/

      Good luck..

      • J’ai bien fournit toutes les IP possibles à l’ACL, mais rien n’y fait.
        En fait, lors de la purge d’une page cachée, il fait un « miss ».
        Donc, à priori, il ne retrouve plus les pages de son cache pour la purge …

      • J’ai trouvé une solution (pas hyper propre) :
        ban(« req.url ~ ^ » + req.url + « $ && req.http.host == « +req.http.host);

        A placer juste avant le return (lookup), après le test client.ip ~ purge.

        Varnish m’indique toujours qu’il n’a pas l’URL dans son cache au moment de la purge, mais au moins j’ai une version « uncached » servie…

  • Pingback: SylvainRamousse » Les sites de référence()

  • Pingback: Booster votre blog Wordpress avec Varnish » Web Design()

  • Pingback: Varnish, un reverse proxy qui soulage vos serveurs | Le blog des nouvelles technologies : Web, Technologies, Développement, Interopérabilité()

  • Pingback: Wordpress sur Nginx et Varnish()

  • Bravo pour cet article très complet. Quelques petites améliorations sont possibles : tout d’abord c’est varnishncsa et non varnishnsca. Et enfin le bloc gérant le http.x-forwarded-for doit être spécifié avant le bloc qui décide si on cache tel ou tel site… sinon les sites non cachés, afficheront 127.0.0.1 en adresse IP cliente. Encore bravo, et merci.

  • Merci ! 2 ans plus tard toujours utile pour d’autres, sur drupal dans mon cas !

  • Pingback: Varnish : mise en place, paramétrage et développement - Arnaud Guignant()

  • Pingback: Basculer facilement entre Apache et Varnish pour votre front-end()

  • Bonjour, qu’y a t’il de mieux à utiliser varnish par rapport à un reverse proxy nginx?

  • Pingback: Varnish devant Wordpress sur Apache - G33Keries.org()

  • Pingback: Installation et configuration Varnish Cache Wordpress - samsufy()

  • Netick

    Merci ! Et pour aller plus loin avec Goaccess => http://www.netick.fr/blog/analyse-de-logs.html