C’était vrai avant 2019, le code du fichier varnish6.vcl était le suivant :

sub vcl_deliver {
    if (resp.http.X-Magento-Debug) {
        if (resp.http.x-varnish ~ " ") {
            set resp.http.X-Magento-Cache-Debug = "HIT";
            set resp.http.Grace = req.http.grace;
        } else {
            set resp.http.X-Magento-Cache-Debug = "MISS";
        }
    } else {
...

Depuis, la configuration Varnish fournie par Magento2 est la suivante :

sub vcl_deliver {
    if (resp.http.x-varnish ~ " ") {
        set resp.http.X-Magento-Cache-Debug = "HIT";
        set resp.http.Grace = req.http.grace;
    } else {
        set resp.http.X-Magento-Cache-Debug = "MISS";
    }
...

Bref, on reçoit le header X-Magento-Cache-Debug même quand le Magento est en mode production.

Est-ce que c’est gênant ?

Certains sites importants laissent l’information, d’autres non. On peut imaginer que cette information peut faciliter les dénis de service.

Dans tous les cas, il suffit de remettre la condition de l’ancienne version pour supprimer l’information…

L’article Faut-il supprimer l’en-tête X-Magento-Cache-Debug ? est apparu en premier sur Alain ARDITI's blog.

La gestion du cache Varnish est alors intégrée à l’outil. C’est à dire que l’outil va générer un en-tête du type TTL (expires ou autre) qui va permettre à Varnish d’appliquer la politique de cache de l’outil. Quand les éléments de sites contiennent des hash dans les URLs, généralement les TTL sont très grands (une année, voire plus). A chaque nouvelle version de cet élément l’outil va modifier le hash, et les utilisateurs pourront ainsi récupérer la nouvelle version sans qu’il n’y ait eu de purge de l’ancienne, puisque l’élément a un nouveau nom !

Dans le cas où les éléments ne changent pas de nom, la home page par exemple, ou des pages Web avec des permaliens, c’est l’outil qui va envoyer une requête de purge à Varnish (généralement une requête HTTP de type PURGE), qui va ainsi rafraîchir son cache et envoyer la nouvelle version.

Ces technologies sont relativement bien rodées sauf dans quelques cas où une extension ne gère pas le cache Varnish ou bien quand on insère dans blocs dans une page ou qu’on fait de l’ESI par exemple.

Dans ces cas, on peut toujours rafraîchir le cache Varnish en ligne de commande avec l’outil d’administration varnishadm ou bien en forgeant une requête de type PURGE, mais ces techniques dépassent souvent les permissions accordés aux webmestres ou leur compétences.

Il reste une solution assez simple d’utilisation, c’est de déclencher une purge Varnish quand l’utilisateur demande une version de la page qui ne provient pas du cache, c’est à dire avec le header HTTP « Cache-Control: no-cache »

C’est le header envoyé par les navigateurs quand on demande le rafraîchissement d’une page. Selon les OS et les navigateurs, le rafraîchissement s’obtient par les raccourcis claviers suivants :

• Windows: Ctrl + F5
• Mac: Command + Shift + R
• Linux: Ctrl + Shift + R

Dans le livre Varnish 6 by example, il est écrit :
« How Varnish deals with Cache-Control
First things first: Varnish doesn’t respect the Cache-Control as a request header, only as a response header. »

Effectivement l’objectif de Varnish ce n’est pas que les utilisateurs contournent le cache et le vide sans arrêt. L’idée de la mise en place du rafraîchissement par un navigateur, c’est de filtrer les IP qui ont le droit de de procéder au rafraîchissement.

On trouve des articles des années 2010 sur Internet qui indiquent comment faire et qui proposent des élément de configuration des fichiers VCL de Varnish datant de Varnish 3 ou 4 :

acl CTRLF5 {
   "127.0.0.1";
}

sub vcl_hit {

  if (client.ip ~ CTRLF5) {
    if (req.http.pragma ~ "no-cache" || req.http.Cache-Control ~ "no-cache")
    {
      set obj.ttl = 0s;
      return(pass);
    }
    else { return(deliver); }
  }
  else { return(deliver); }
}

Bref, quand on travaille sur Varnish 6 avec des CDN ou des proxy SSL type Nginx, on ne risque pas de faire fonctionner le rafraîchissement avec le code ci-dessus !

La configuration actualisée pour Varnish 6 serait du type :

# VCL version 5.0 is not supported so it should be 4.0 even though actually used Varnish version is 6
vcl 4.0;
import std;
...

# Declaration des IP autorisées à purger les pages
purge {
  "localhost";
  "127.0.0.1";
  "::1";
  "78.201.202.159"; # IP de ma maison
  "90.63.253.70";   # toHero (Orange)
  "212.114.18.211"; # toHero (Free)
}
...

sub vcl_hit {
    # Comme on est derrière Nginx, client.ip est l'IP du proxy pour tous les clients !!!
    # Si on se basait sur client.ip, il n'y aurait aucun filtrage...
    # On utilise X-Real-IP, sauf si la requête provient de localhost
    if ((req.http.X-Real-IP) && (std.ip(req.http.X-Real-IP) ~ purge) ||
            client.ip ~ purge) {
        if (req.http.pragma ~ "no-cache" || req.http.Cache-Control ~ "no-cache")
        {
          ban("obj.http.X-Req-URL ~ " + req.url);
          return (restart);
        }
    }
...

Une fois cette configuration installée, on peut procéder à quelques tests !

aa2@apollo:~$ curl -s -k -D - -o /dev/null "https://alain.arditi.fr/"
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 22 Feb 2023 14:51:19 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Last-Modified: Sun, 06 Nov 2022 21:39:44 GMT
Vary: Accept-Encoding
Age: 24
X-Cache: HIT
Accept-Ranges: bytes

aa2@apollo:~$

# On force le rafraichissement
aa2@apollo:~$ curl -s -k -H "Cache-control: no-cache" -D - -o /dev/null "https://alain.arditi.fr/"
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 22 Feb 2023 14:51:25 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Last-Modified: Sun, 06 Nov 2022 21:39:44 GMT
Vary: Accept-Encoding
Age: 0
X-Cache: MISS
Accept-Ranges: bytes

aa2@apollo:~$
aa2@apollo:~$ curl -s -k -D - -o /dev/null "https://alain.arditi.fr/"
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 22 Feb 2023 15:33:08 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 31761
Connection: keep-alive
Last-Modified: Sun, 06 Nov 2022 21:39:44 GMT
Vary: Accept-Encoding
Age: 14
X-Cache: HIT
Accept-Ranges: bytes

aa2@apollo:~$ 

# Test depuis une IP qui n'est pas dans l'access list "purge" :
arditi-host3:~# curl -s -k -H "Cache-control: no-cache" -D - -o /dev/null "https://alain.arditi.fr/"
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 22 Feb 2023 15:35:23 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 31761
Connection: keep-alive
Last-Modified: Sun, 06 Nov 2022 21:39:44 GMT
Vary: Accept-Encoding
Age: 149
X-Cache: HIT
Accept-Ranges: bytes

arditi-host3:~#

…..

L’article Forcer le rafraichissement du cache Varnish avec Ctrl+F5 ! est apparu en premier sur Alain ARDITI's blog.

Pour l’installer, rien de plus simple, il suffit de faire un lien symbolique sur un des « aspects » disponibles pour ce plugin, qu’on obtient par la commande :

aa2:~# munin-run varnish_transfer_rates suggest
memory_usage
request_rate
backend_traffic
transfer_rates
threads
bad
uptime
expunge
objects
hit_rate
aa2:~#

Mais avant de pouvoir lancer cette commande pour connaître les « aspects » de ce plugin, il fallait déjà faire un lien symbolique, donc lire le contenu du plugin ! La on choisit l’aspect « transfer_rates ». Pour installer le plugin qui va fournir les « transfer_rates » de Varnish, il faut faire le lien suivant :

aa2:~# ln -s /usr/share/munin/plugins/varnish_ /etc/munin/plugins/varnish_transfer_rates
aa2:~#

A cette étape, la configuration est prête pour tester le plugin. On lance la commande suivante pour vérifier les valeurs que renvoie le plugin :

aa2:~# munin-run varnish_transfer_rates 
.....
Could not get hold of varnishd, is it running?

no element found at line 1, column 0, byte 0 at /usr/lib/x86_64-linux-gnu/perl5/5.28/XML/Parser.pm line 187.
aa2:~#

Pas de réponse, on attend les ….. puis on obtient une erreur ! Cette erreur provient de varnishstat. Quand on lance varnishstat pourtant tout fonctionne :

aa2:~# varnishstat  -x
<?xml version="1.0"?>
<varnishstat timestamp="2021-03-08T22:33:50">
	<stat>
		<name>MGT.uptime</name>
		<value>520285</value>
		<flag>c</flag>
		<format>d</format>
		<description>Management process uptime</description>
	</stat>
	<stat>
		<name>MGT.child_start</name>
		<value>1</value>
		<flag>c</flag>
		<format>i</format>
		<description>Child process started</description>
	</stat>
...
...
</varnishstat>
aa2:~#

Alors que se passe-t-il ? On essaie avec les options de débug :

aa2:~# munin-run --debug --pidebug varnish_transfer_rates 
# Processing plugin configuration from /etc/munin/plugin-conf.d/README
# Processing plugin configuration from /etc/munin/plugin-conf.d/dhcpd3
# Processing plugin configuration from /etc/munin/plugin-conf.d/munin-node
# Processing plugin configuration from /etc/munin/plugin-conf.d/spamstats
# Processing plugin configuration from /etc/munin/plugin-conf.d/varnish4_
# Processing plugin configuration from /etc/munin/plugin-conf.d/varnish5_
# Processing plugin configuration from /etc/munin/plugin-conf.d/varnish_
# Setting /rgid/ruid/ to /113/65534/
# Setting /egid/euid/ to /113 113/65534/
# Setting up environment
# About to run '/etc/munin/plugins/varnish_transfer_rates'
.....
Could not get hold of varnishd, is it running?

no element found at line 1, column 0, byte 0 at /usr/lib/x86_64-linux-gnu/perl5/5.28/XML/Parser.pm line 187.
aa2:~#

Toujours la même erreur. En y regardant de plus près on s’aperçoit que le plugin est lancé avec l’euid 113 qui est l’id de l’utilisateur munin sur ma machine. Mais comme le process Varnish tourne sous l’utilisateur vcache, le plugin ne peut pas contacter Varnish, d’où l’erreur. La méthode pour corriger ce problème est de lancer le plugin Varnish avec l’utilisateur « vcache ». Pour ceci, on crée un fichier de configuration du plugin qui indique d’utiliser « vcache » :

aa2:~# cat /etc/munin/plugin-conf.d/varnish_ 
[varnish_*]
    user vcache
aa2:~# 
aa2:~# munin-run varnish_transfer_rates 
aa2:~# 
aa2:~# munin-run --debug --pidebug varnish_transfer_rates 
# Processing plugin configuration from /etc/munin/plugin-conf.d/README
# Processing plugin configuration from /etc/munin/plugin-conf.d/dhcpd3
# Processing plugin configuration from /etc/munin/plugin-conf.d/munin-node
# Processing plugin configuration from /etc/munin/plugin-conf.d/spamstats
# Processing plugin configuration from /etc/munin/plugin-conf.d/varnish4_
# Processing plugin configuration from /etc/munin/plugin-conf.d/varnish5_
# Processing plugin configuration from /etc/munin/plugin-conf.d/varnish_
# Setting /rgid/ruid/ to /113/109/
# Setting /egid/euid/ to /113 113/109/
# Setting up environment
# About to run '/etc/munin/plugins/varnish_transfer_rates'
aa2:~#

Le plugin fonctionne, mais ne renvoie rien !!!
On tombe sur le bug : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959812

En cherchant les plugins Varnish pour Munin, on trouve beaucoup de choses. Qui vont de Varnish 2 à Varnish 5. Mais sous Buster, on est en Varnish 6. Tous les plugins Varnish ont la même source, la version de 2009. Mais on ne sait pas exactement avec quelle version de Varnish ils fonctionnent. J’en ai essayé 3 différents, et sans aucun doute, le bon est celui-ci : https://gallery.munin-monitoring.org/plugins/munin-contrib/varnish5_/

Il faut récupérer le source, faire le lien dans le répertoire des plugins et mettre l’utilisateur « vcache » ou « root » dans la configuration. Là, j’ai utilisé le hit_rate comme « aspect » :

aa2:~# ln -s /usr/share/munin/plugins/varnish5_ /etc/munin/plugins/varnish5_hit_rate
aa2:~#
aa2:~# cat /etc/munin/plugin-conf.d/varnish5_ 
[varnish5_*]
    user vcache
aa2:~#
aa2:~# munin-run varnish5_hit_rate 
client_req.value 2955
cache_hitpass.value 0
cache_hitmiss.value 12
cache_hit.value 2228
cache_miss.value 715
aa2:~#

On a bien un résultat cette fois !
Remarque, le client_req est calculé comme la somme des 4 valeurs cache_*. Alors que la commande varnishstat renvoie un client_req de 9585 ! Cette dernière valeur représente toutes les requêtes reçues par Varnish, y compris les « pass ». Donc avec le plugin « varnish5_ » on n’a que les requêtes qui sont sensées être en cache. Ce qui est logique pour un calcul de hit ratio, mais qui ne montre pas la totalité des requêtes reçues.

On retrouve ci-dessus un hit ratio dont la somme des 4 composantes fait 100.

Références :
Munin
Paquet Munin pour Debian Buster

L’article Munin : le plugin Varnish sous Debian Buster est apparu en premier sur Alain ARDITI's blog.

L’apport de Varnish est important, par contre, on ne voit pas ce qu’apporte le plugin de cache WordPress. Effectivement, sur les pages statiques lorsque Varnish est installé, WordPress ne travaille plus. On verra néanmoins l’intérêt du plugin en conclusion.

J’ai utilisé le plugin WordPress de cache WP Fastest Cache pour faire les tests, mais globalement tous les plugins de cache WordPress travaillent de la même manière. Ils créent la page sur le disque et WordPress, ou plutôt le serveur Web, Apache ou Nginx, renvoie directement la page depuis le disque. Il ne devrait pas y avoir beaucoup de différence entre les différents plugins de cache pour WordPress. Donc celui-ci ou un autre, ce n’est pas la question dans cet article.

l’infrastructure cible est une petite VM avec 1 vcpu et 500Mo de RAM sur VirtualBox de mon MacBook Air 2017. L’injecteur JMeter est sur une autre VM de ma machine, les latences sont donc très faibles par rapports aux latences sur Internet.

On va tester un scénario de 7 pages statiques :

Sur 3 configurations différentes

1. WordPress avec Varnish
2. WordPress sans Varnish et sans plugin
3. WordPress sans Varnish et avec le plugin WP Fastest Cache

JMeter est configuré pour lancer 30 threads. Il passe de 1 à 30 en 5 minutes et reste 2 minutes à 30 threads, sans aucun délai entre les threads. Ce n’est pas très réaliste, c’est juste un test technique. On verra d’ailleurs dans l’analyse que le serveur est saturé bien avant d’arriver au plateau des 30 threads dans les 3 cas.

WordPress avec Varnish

On retrouve les performances qu’on avait déjà vues dans l’article Booster son WordPress avec Varnish 5/4. Dans cette configuration, on arrive à produire plus de 30Mbps de flux depuis le serveur.

La connexion initiale lors de l’accès à la « Home page » prend du temps. C’est le temps de la création de la communication TCP/IP et la mise en place du SSL avec le serveur Nginx. Et au début de chaque threads, il y a une reconnection afin de simuler la réalité.

La latence ci-dessus est l’équivalent du Time To First Byte (TTFB). On voit que les latences sont exceptionnelles basses sauf pour la « Home page » en violet. Quelque soit la page, Varnish la sort de la mémoire sans aucun traitement. Il n’y a donc aucune différence entre les pages.

On va plutôt étudier les temps de réponse qui sont plus démonstratifs, sur les autres configurations.

Ici, on voit que les temps de réponse sont très similaires au TTFB, puisqu’ensuite, s’ajoute le temps de transfert de la page à l’intérieur du MacBook !

WordPress sans Varnish sans plugin de cache

Par contre, avec la deuxième configuration, sans Varnish et sans plugin, les temps de réponse sont nettement plus élevés

L’échelle du graphe est 4 fois plus grande, on atteint la seconde. Et on note une différence entre les pages, cette fois-ci. La « Home » est en violet, mais dépassée par les catégories. En troisième c’est la page « 5 – /2021/02/01/nouvel-article/ » qui est plus lourde que les autres, car elle a plus de contenu. Le temps de réponse est quasiment le même pour les autres pages.

WordPress sans Varnish avec plugin de cache

Avec la troisième configuration, sans Varnish mais avec le plugin WP Fastest Cache, les temps de réponse sont meilleurs que ceux de la configuration précédente :

L’échelle du graphique est divisé par 3 par rapport au précédent, on atteint les 350 ms.

Maintenant qu’on a vu le détail des pages et les temps de réponse, on va pouvoir comparer les graphes de consommation de ressources du serveur.
Dans les graphes qui suivent, les 3 périodes correspondent aux 3 configurations dans l’ordre suivant :

1. WordPress avec Varnish
2. WordPress sans Varnish et sans plugin
3. WordPress sans Varnish et avec le plugin WP Fastest Cache

La première période, celle « Avec Varnish » montre que la CPU est tout de même tout utilisée.
C’est l’effet HTTPS ! Toute la CPU est utilisée par Nginx pour la terminaison SSL. C’est à se demander si on ne ferait pas mieux d’abandonner le SSL pour les sites statiques afin diminuer la consommation énergétique du numérique !

Pour les deuxièmes et troisièmes périodes, on atteint les 100% d’utilisation de la CPU. Dans ces 2 cas, on constate une contention de la CPU. Dans le premier cas, sans Varnish sans plugin, les 100% de CPU sont atteints de suite. Dans le cas sans Varnish mais avec plugin, les 100% sont atteints dans les 3 minutes. On note plus d’activité système dans ce dernier cas. En effet, on va le confirmer sur les débits, avec le plugin de cache, le débit est beaucoup plus élevé, donc les entrées/sorties sont plus sollicitées.

On voit clairement avec ce graphe de débit, la capacité à fournir des pages lorsque Varnish fonctionne. La contention se situe au niveau du réseau avec Varnish. A 36Mbps, on est au maximum de ce que la VM peut produire. Pour les 2 autres configurations les débits sont beaucoup plus faibles, la contention se situe bien au niveau de la CPU.

Le graphe du Load average est l’inverse de celui du débit ! On confirme la contention au niveau de la CPU.

Regardons les 2 graphes MySQL

Là aussi, on confirme les données précédentes. Avec Varnish, il n’y a pas de requêtes. Toutes les pages sont en RAM. Sans Varnish, WordPress récupère une partie de ses données depuis MySQL. Sans plugin, le site fait deux fois plus de requêtes.

Avec le plugin de cache WordPress, le site fournit presque trois fois plus de pages, c’est pour cette raison qu’il y a plus de données extraites du MySQL et avec moins de requêtes. On suppose que les traitements sont optimisés pour extraire le maximum de données en un minimum de requêtes.

Le bilan en nombre de pages pour les 3 configurations avec le même scénario qui dure 7 minutes est le suivant :

1. WordPress avec Varnish :
   190 000 pages
   débit max de 500 pages/s
2. WordPress sans Varnish et sans plugin :
   18 000 pages
   débit max de 46 pages/s
3. WordPress sans Varnish et avec le plugin WP Fastest Cache :
   56 000 pages
   débit max de 150 pages/s

Même si les graphes ne sont pas toujours parlants, ce bilan permet de remettre les résultats en perpective :

Avec Varnish le site WordPress produit 3 fois plus de pages (indépendamment du plugin de cache), que lorsque WordPress est configuré avec un plugin de cache.
Avec le plugin de cache le site produit 3 fois plus de pages que lorsque WordPress n’a pas de plugin.
Il faut quand même noter qu’il y a une saturation réseau avec Varnish et que sans SSL on pourrait améliorer les performances d’un facteur au moins 2 !

Le bilan est clair. Les plugins de cache apportent une performance significative à WordPress. Il ne faut donc pas s’en priver puisqu’ils s’installent de manière quasiment automatique. C’est une optimisation facile à mettre en place chez les hébergeurs qui fournissent du WordPress clé en main. Pour passer à la vitesse supérieur, il faut ajouter Varnish.

Alors pourquoi ne pas installer Varnish et c’est tout !

Parce que les plugins de cache optimisent l’expérience utilisateur ! Nous n’avons pas regardé ce qui se passe lorsqu’on charge une page du point de vue utilisateur. Mais les optimisations comme la minification des CSS, du JavaScript ou l’allègement des images sont essentielles pour le ressenti utilisateur ! Et c’est un critère de poids pour les outils d’analyse de sites.

Lors des tests de charges, nous n’étudions pas ces aspects. Le bilan est clair, il faut Varnish ET un plugin de cache si on veut améliorer les performances de WordPress sous tous les aspects.

Donc à la question : WordPress : Plugin de cache ou Varnish ?
Je réponds : les 2 mon capitaine !

La dernière optimisation pour les performances c’est l’addition d’un CDN. Le problème c’est qu’ils sont, soit payants, soit nécessitent de laisser la gestion du domaine, comme CloudFlare. Mais c’est un « must have » pour les sites à forte audience internationale.

Petite réflexion sur les tests menés ci-dessus.

Dans les 3 configurations, on atteint les limites de la VM bien avant le plateau des 30 threads. On pourrait dire, il valait mieux aller à 20 threads ou moins selon la configuration, pour voir les graphes monter en fonction de la charge sans aller jusqu’à la saturation. Alors effectivement, dans ce cas les graphes auraient été plus lisibles.

Mais en fait, tant que les scénarios ne font pas d’erreur, et là, pour nos 3 scénarios, on a 0% d’erreur, on peut ajouter de la charge et saturer le système, ce n’est pas très grave. On atteint les limites plus vite. Et comme on cherche à comparer les limites des 3 configurations autant y aller !

Alors que se passe-t-il lorsqu’on atteint une contention et que WordPress continue à répondre sans erreur ?

Et bien, il répond plus lentement ! C’est comme un bouchon d’automobilistes sur la route. On passe toujours le même nombre de voiture par tronçon, mais plus lentement. C’est la raison de l’augmentation des temps de réponse. Plus on ajoute de threads, plus les temps de réponses augmentent, le débit restant à peu près inchangé pendant tout le restant du test.
Le critère à retenir, c’est vraiment le débit du site, ou le nombre de pages par seconde. On voit très bien pendant les tests de charge que cette valeur va se figer dès qu’on atteint un certain nombre de threads, qu’on mette des timers, qu’on simule les utilisateurs ou pas, ce nombre ne varie pas. Ce nombre est la limite de l’infrastructure.

Si on ajoute des threads, les pages arrivent plus lentement, car il y une contention, c’est le phénomène « bouchon ». Si on continue à ajouter des threads, passé une autre limite on commence à voir des erreurs. A partir de ce point là, le test n’est plus pertinent.

Les erreurs sont donc un point à surveiller lors des tests avec JMeter, et les assertions sont la réponse à cette exigence !

Références :
WordPress
JMeter
Varnish
WP Fastest Cache

L’article WordPress : Plugin de cache ou Varnish ? est apparu en premier sur Alain ARDITI's blog.

Vous avez un WordPress 5.6, votre site est installé sur une distribution Debian Buster avec Apache/PHP/MySQL. Comme Varnish ne fait pas de SSL, il vous faudra un accélérateur SSL comme Nginx ou HAProxy. Varnish va s’intercaler entre le WordPress et le composant qui gère la terminaison SSL.

On peut installer Varnish 6.1 avec la commande 

$ sudo apt install varnish
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
libjemalloc2 libvarnishapi2 Suggested packages:
varnish-doc
The following NEW packages will be installed:
libjemalloc2 libvarnishapi2 varnish
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 1,207 kB of archives.
After this operation, 3,397 kB of additional disk space will be used. Do you want to continue? [Y/n] y
....
$

Jusque là, comme Varnish s’installe par défaut sur le port 6081, il n’y a aucun impact sur le Wordpress !

On prépare la configuration de Varnish qui se trouve dans /etc/varnish/default.vcl

Sauvegardez la version d’origine avant de la modifier avec la version à télécharger ici !

Dans ce fichier, il faut vérifier le paragraphe 

backend default {
    .host = "localhost";  # WordPress sur trouve sur le même serveur que Varnish
    .port = "8080";
    .....

qui définit l’endroit où seront redirigées les requêtes qui arrivent depuis Varnish.

Etape 1 : Modifier les ports d’écoute d’Apache et de Varnish

Afin que Apache écoute sur le port 8080, il faut modifier 2 fichiers de configuration d’Apache :

On passe Listen 80 à Listen 8080 dans le fichier /etc/apache2/ports.conf et dans la configuration du site WordPress, il faut passer le 80 à 8080 également :

$ less /etc/apache2/sites-enabled/000-default.conf
<VirtualHost *:80>
# The ServerName directive sets the request scheme, hostname and port that
....

de manière à obtenir :

$ less /etc/apache2/sites-enabled/000-default.conf
<VirtualHost *:8080>
# The ServerName directive sets the request scheme, hostname and port that
....

Le redémarrage d’Apache permet la prise en compte du changement de port :

$ sudo apachectl -t
Syntax OK
$ 
$ sudo systemctl restart apache2
$ sudo systemctl status apache2
● apache2.service - The Apache HTTP Server
   Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2021-01-25 10:01:27 CET; 9h ago
     Docs: https://httpd.apache.org/docs/2.4/
 Main PID: 26634 (apache2)
    Tasks: 13 (limit: 4696)
   Memory: 244.9M
   CGroup: /system.slice/apache2.service
           ├─ 3666 /usr/sbin/apache2 -k start
           ├─ 5662 /usr/sbin/apache2 -k start
           ├─ 5663 /usr/sbin/apache2 -k start
           ├─ 6443 /usr/sbin/apache2 -k start
           ├─26634 /usr/sbin/apache2 -k start
           ├─26637 /usr/sbin/apache2 -k start
           ├─26639 /usr/sbin/apache2 -k start
           ├─26899 /usr/sbin/apache2 -k start
           ├─26900 /usr/sbin/apache2 -k start
           ├─26901 /usr/sbin/apache2 -k start
           └─26920 /usr/sbin/apache2 -k start
Jan 25 10:01:27 aa2 systemd[1]: Starting The Apache HTTP Server...
Jan 25 10:01:27 aa2 systemd[1]: Started The Apache HTTP Server.
$

On modifie le port d’écoute de Varnish pour passer du port par défaut 6081 au port 80, c’est l’option -a de la ligne de commande ExecStart dans le fichier /etc/systemd/system/varnish.service qu’on aura copié depuis la version distribuée :

$ sudo cp /lib/systemd/system/varnish.service /etc/systemd/system/varnish.service
$
## et modifié comme suit :
$ cat /etc/systemd/system/varnish.service
[Unit]
Description=Varnish HTTP accelerator Documentation=https://www.varnish-cache.org/docs/6.1/ man:varnishd
[Service]
Type=simple
LimitNOFILE=131072
LimitMEMLOCK=82000
ExecStart=/usr/sbin/varnishd -j unix,user=vcache -F -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256m ExecReload=/usr/share/varnish/varnishreload
ProtectSystem=full 
ProtectHome=true 
PrivateTmp=true 
PrivateDevices=true
[Install] 
WantedBy=multi-user.target 
$

On lance la prise en compte de cette modification et on redémarre Varnish :

$ sudo systemctl daemon-reload
$ sudo systemctl restart varnish
$ sudo systemctl status varnish
● varnish.service - Varnish HTTP accelerator
   Loaded: loaded (/lib/systemd/system/varnish.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2021-01-25 19:46:50 CET; 7s ago
     Docs: https://www.varnish-cache.org/docs/6.1/
           man:varnishd
 Main PID: 11354 (varnishd)
    Tasks: 217 (limit: 4696)
   Memory: 116.4M
   CGroup: /system.slice/varnish.service
           ├─11354 /usr/sbin/varnishd -j unix,user=vcache -F -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256m
           └─11366 /usr/sbin/varnishd -j unix,user=vcache -F -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256m
Jan 25 19:46:50 aa2 systemd[1]: Started Varnish HTTP accelerator.
Jan 25 19:46:52 aa2 varnishd[11354]: Debug: Version: varnish-6.1.1 revision efc2f6c1536cf2272e471f5cff5f145239b19460
Jan 25 19:46:52 aa2 varnishd[11354]: Debug: Platform: Linux,4.19.0-9-amd64,x86_64,-junix,-smalloc,-sdefault,-hcritbit
Jan 25 19:46:52 aa2 varnishd[11354]: Version: varnish-6.1.1 revision efc2f6c1536cf2272e471f5cff5f145239b19460
Jan 25 19:46:52 aa2 varnishd[11354]: Platform: Linux,4.19.0-9-amd64,x86_64,-junix,-smalloc,-sdefault,-hcritbit
Jan 25 19:46:52 aa2 varnishd[11354]: Debug: Child (11366) Started
Jan 25 19:46:52 aa2 varnishd[11354]: Child (11366) Started
Jan 25 19:46:52 aa2 varnishd[11354]: Info: Child (11366) said Child starts
Jan 25 19:46:52 aa2 varnishd[11354]: Child (11366) said Child starts
$ 

Etape 2 : purger le cache Varnish

Une fois installé, on peut vérifier l’amélioration des performances de la mise en place de Varnish.

Pour vérifier la bon fonctionnement de Varnish, il faut gérer la purge. Sur le serveur Varnish, il suffit de lancer la commande suivante pour vider toutes les URLs mises en cache :

$ sudo varnishadm "ban req.url ~ ."
$

Le . de l’expression régulière veut dire : 0 ou 1 caractère et n’importe lequel. Toutes les URLs vont satisfaire la condition « ~ . » , donc cette expression va bannir toutes les URLs du cache.

La première requête suivant cette purge doit montrer un entête X-Cache: MISS

La deuxième requête identique doit montrer un entête X-Cache: HIT

On pourrait aussi purger des URLs avec une requête du type PURGE, puisqu’on a a géré ce cas dans le fichier default.vcl. Cette configuration permet de faire des purges à distance, sans être loggé sur le serveur et pourra aussi être utilisée par des plugins WordPress pour vider le cache lorsqu’on publie un article.

Par exemple pour purger la page de cet article, dont l’URL est : https://alain.arditi.fr/2021/02/09/booster-son-wordpress-avec-varnish/ il suffit de lancer la requête suivante sur la machine qui héberge le Varnish :

$ curl -D - -X PURGE "http://localhost/2021/02/09/booster-son-wordpress-avec-varnish/"
HTTP/1.1 200 Purged.
Date: Tue, 09 Feb 2021 13:45:18 GMT
Server: Varnish
X-Varnish: 229742
Content-Length: 0
Accept-Ranges: bytes
Connection: keep-alive
$ sudo varnishadm 
200        
-----------------------------
Varnish Cache CLI 1.0
-----------------------------
Linux,4.19.0-9-amd64,x86_64,-junix,-smalloc,-sdefault,-hcritbit
varnish-6.1.1 revision efc2f6c1536cf2272e471f5cff5f145239b19460
Type 'help' for command list.
Type 'quit' to close CLI session.
varnish> ban.list
200        
Present bans:
1612878318.148724     0 -  obj.http.X-Req-URL == /2021/02/09/booster-son-wordpress-avec-varnish/
1612878297.553181     0 C  
1612878289.407936     0 C  
1612878281.014556     0 C  
1612878237.731221     0 C  
1612864182.318939    44 C  
varnish> quit
500        
Closing CLI connection
$

On peut vérifier que la purge a bien fonctionné, en enchainant 2 fois la même requête et en regardant l’entête X-Cache :

$ curl -s -D - "https://alain.arditi.fr/2021/02/09/booster-son-wordpress-avec-varnish/" -o /dev/null
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 09 Feb 2021 13:59:29 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
X-Frame-Options: sameorigin
Age: 0
X-Cache: MISS
Accept-Ranges: bytes
$ curl -s -D - "https://alain.arditi.fr/2021/02/09/booster-son-wordpress-avec-varnish/" -o /dev/null
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 09 Feb 2021 14:03:34 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 32894
Connection: keep-alive
Vary: Accept-Encoding
X-Frame-Options: sameorigin
Age: 245
X-Cache: HIT
Accept-Ranges: bytes
$

Dernier point concernant la purge, on peut vérifier que la purge est interdite depuis une IP externe et génère un code d’erreur 405 qui se trouve dans le fichier /etc/varnish/default.vcl :

$ curl -D - -X PURGE "https://alain.arditi.fr/2021/02/09/booster-son-wordpress-avec-varnish/"   
HTTP/1.1 405 This IP is not allowed.
Server: nginx
Date: Tue, 09 Feb 2021 14:11:14 GMT
Content-Length: 0
Connection: keep-alive
X-Varnish: 360523
$

A ce stade, nn est prêt à faire des mesures sur l’efficacité des temps de réponse.

Etape 3 : mesurer les temps de réponse unitaires

On peut regarder le temps de chargement d’une page avec cUrl !
On prépare un fichier pour le formatage des temps de réponse comme suit :

$ cat curl-format.txt
       time_connect:  %{time_connect}\n
 time_starttransfer:  %{time_starttransfer}\n
                    ----------\n
         time_total:  %{time_total}\n
$ 

Ce format pour cUrl est un format réduit, qui contient uniquement les 3 indicateurs qui nous intéressent. Ce qui produit un time_total qui n’est pas toujours la somme de time_connect + time_starttransfer.

Pour information, le format qui permet d’avoir tous les timers est le suivant :

    time_namelookup:  %{time_namelookup}\n
       time_connect:  %{time_connect}\n
    time_appconnect:  %{time_appconnect}\n
   time_pretransfer:  %{time_pretransfer}\n
      time_redirect:  %{time_redirect}\n
 time_starttransfer:  %{time_starttransfer}\n
                    ----------\n
         time_total:  %{time_total}\n

On lance une requête après le vidage du cache :

$ curl -s -D - -w "@curl-format.txt" -o /dev/null -s "http://localhost/"
HTTP/1.1 200 OK
Date: Mon, 25 Jan 2021 16:00:28 GMT
Vary: Accept-Encoding
X-Frame-Options: sameorigin
Content-Type: text/html; charset=UTF-8
Age: 0
X-Cache: MISS
Accept-Ranges: bytes
Transfer-Encoding: chunked
Connection: keep-alive
       time_connect:  0.001480
 time_starttransfer:  0.030051
                    ----------
         time_total:  0.030324
$

On remarque que l’en-tête X-Cache vaut MISS.
La page est servie depuis Apache car elle n’est pas stockée au niveau de Varnish.
Mais si on exécute la même requête encore une fois on obtient :

$ curl -s -D - -w "@curl-format.txt" -o /dev/null -s "http://localhost/"
HTTP/1.1 200 OK
Date: Mon, 25 Jan 2021 16:00:28 GMT
Vary: Accept-Encoding
X-Frame-Options: sameorigin
Content-Type: text/html; charset=UTF-8
Age: 3
X-Cache: HIT
Accept-Ranges: bytes
Content-Length: 30108
Connection: keep-alive
        time_connect:  0.001529
  time_starttransfer:  0.002299
                    ----------
         time_total:  0.002713
$

On divise le temps de réponse par un facteur 10 !!
Si on demande la même page directement depuis Apache, on obtient :

$ curl -s -D - -w "@curl-format.txt" -o /dev/null "http://localhost:8080/"
HTTP/1.1 200 OK
Date: Mon, 25 Jan 2021 16:00:39 GMT
Server: Apache
Vary: Accept-Encoding
X-Frame-Options: sameorigin
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8
        time_connect:  0.001666
 time_starttransfer:  0.026801
                    ----------
         time_total:  0.027680
$

soit un temps de réponse voisin de celui de Varnish quand la page n’est pas cachée. Ce facteur 10 prouve l’intérêt de Varnish, qui va pouvoir servir tous les contenus statiques, images, js et css, et pages également, lorsqu’elles n’ont pas de cookies de session, beaucoup plus rapidement qu’un serveur Apache !

Sur ce test, on voit l’efficacité de l’addition de Varnish sur les contenus statiques en terme de temps de réponse unitaire. C’est donc un gain pour l’expérience utilisateur !

L’autre bénéfice est celui de la tenue en charge, qu’on peut mesurer avec des outils comme JMeter.

C’est ce que nous allons étudier dans les pages suivantes.

L’article Booster son WordPress avec Varnish 1/4 est apparu en premier sur Alain ARDITI's blog.

JMeter est un « injecteur » qui permet de simuler le parcours de plusieurs internautes et donc de produire de l’audience, de la charge, sur un serveur afin de vérifier son comportement, sa tenue en charge !

Le sujet de la tenue en charge est assez vaste. Ici, on réduira le périmètre aux pages statiques puisque pour les pages dynamiques, le Varnish ne va pas pouvoir utiliser son cache.

Les tests ci dessous ont été effectués sur une VM WordPress de test avec très peu de ressources afin de mieux visualiser les limites de la VM.
La VM WordPress dispose d’un seul vcpu et de 500Mo de RAM et elle se trouve sur mon hyperviseur VirtualBox sur un Macbook Air de 2017 ! Le WordPress utilise le plugin de cache WP Fastest Cache qui génère les pages prêtes à l’emploi sur le disque. A noter, que comme JMeter n’interprète pas le JavaScript ni les feuilles de style CSS, les optimisations de minification de JS, de CSS, l’allègement du poids des images n’apparaissent pas dans les résultats de ces tests.

Dans les paragraphes ci dessous, notre objectif consiste uniquement à « visualiser » l’apport du composant Varnish. On lance un premier test sans Varnish, puis on relance le même test en activant Varnish.

Comme lors du deuxième test, on constate que la VM a encore de la ressource, on lancera un troisième test en doublant le nombre de threads, qui passent de 40 à 80.

Test n°1 : 40 threads sans Varnish

On lance 40 threads JMeter sur le site en SSL avec Nginx, sans cache Varnish.
Les résultats bruts de JMeter : nombre de requêtes 406 128, 0% d’erreur.

La légende des abscisses indique le jour 09 (Février) suivi de l’heure.
Les 40 threads sont atteints à 22h27. C’est à partir de ce moment qu’on atteint le maximum de la charge.

Les métriques de la VM sont les suivantes. La granularité de l’outil de graphes Munin, utilisé pour ces tests est de 5 minutes.

On a exactement le même nombre de requêtes traitées par Nginx et par Apache puisqu’il n’y pas de cache. Toutes les requêtes sont transmises à Apache.

Les métriques coté JMeter sont les suivantes. La granularité des JMeter est de 1 minutes, c’est donc beaucoup plus précis dans notre cas que les graphes Munin.

Les temps de réponse sont en millisecondes car JMeter se trouve sur le même hyperviseur que la VM WordPress. On voit que la latence augmente graduellement en fonction de la charge. est perturbée à 22h32 et à 22h35.

On fait le même constat sur les temps de réponse. La courbe violette correspond à une page qui pèse 10 fois plus que les autres, son temps de réponse est plus élevé à cause du temps de transfert.

On voit que qu’à partir de 22h27 le débit se dégrade, avec une perturbation à 22h32. On suppose que cette pointe est un artefact lié à la charge. Néanmoins, à partir de 40 thread, il y a un comportement erratique qu’on ne voit pas bien sur les graphes Munin. En y regardant de plus près, on voit que sur les graphes Munin les mesures de 22h30 sont plus faibles que les mesures de 22h25, mais surtout que les mesures de 22h35 sont beaucoup plus faibles, alors qu’il y a toujours 40 threads jusqu’à 22h37. C’est le signe que la VM ne répond plus correctement, on a une dégradation de son comportement à 40 threads.

On va pouvoir constater les différences avec le même test, mais avec Varnish activé qui va cacher toutes les page.

L’article Booster son WordPress avec Varnish 2/4 est apparu en premier sur Alain ARDITI's blog.

On lance 40 threads JMeter sur le site en SSL avec Nginx, mais cette fois avec le cache Varnish et avec le plugin de cache WordPress WP Fastest Cache.
Les résultats bruts de JMeter : nombre de requêtes 482 789, 0% d’erreur.

La légende des abscisses indique le jour 09 (Février) suivi de l’heure.
Les 40 threads sont atteints à 23h35. C’est à partir de ce moment qu’on atteint le maximum de la charge.

Les métriques de la VM sont les suivantes. La granularité de l’outil de graphes Munin, utilisé pour ces tests est de 5 minutes.

Il faut noter l’amélioration du maximum. Dans le scénario sans Varnish on arrive à 170 requêtes/s, ici on monte à 220 requêtes/s.

Apache traite cent fois moins de requête avec Varnish. En fait dans le scénario, il y a une requête dynamique dans le scénario et qui ne peut pas être cachée par Varnish. Elle est toujours passée à Apache. On note également sur les deux graphes précédents, mais on retrouvera ce comportement sur tous les graphes suivants, qu’on bien un plateau identique au plateau de nombre de threads. Contrairement au scénario 1, sans Varnish où la VM ne suit plus les thread de l’injecteur JMeter une fois au maximum. Ce qui confirme la saturation de la VM dans le scénario 1.

La charge de la VM n’est pas significative, il ne faut pas tenir compte des petites variations qui sont sous la valeur 0,2.

Les valeurs sont tellement faibles que ce graphe n’est pas significatif. Ici on a des millièmes de requêtes par seconde.

Les métriques coté JMeter sont les suivantes. La granularité des JMeter est de 1 minutes, c’est donc beaucoup plus précis dans notre cas que les graphes Munin.

La latence ne varie quasiment pas avec la charge. Il n’y a pas de saturation. On note également une diminution de la latence par un facteur 10 au moins. On voit la capacité de Varnish à cracher du HTTP !

Même constat, les temps de réponse sont exceptionnels et ne varient pas. Sauf pour la courbe violette correspond à une page qui pèse 10 fois plus que les autres.

Trois conclusions à tirer de ce deuxième test :

1. Les latences et les temps de réponse sont exceptionnels
2. Le nombre de requêtes fournies par seconde augmente de 30%, parce que les pages sont servies plus vite.
3. A 40 threads, la VM n’est pas saturée, contrairement au test précédent qui avait atteint les limites. Les graphes JMeter et Munin suivent le graphe des threads !

On va doit pouvoir pousser le test à 80 threads

L’article Booster son WordPress avec Varnish 3/4 est apparu en premier sur Alain ARDITI's blog.

On lance 80 threads JMeter sur le site en SSL avec Nginx, avec le cache Varnish et avec le plugin de cache WordPress WP Fastest Cache afin d’essayer de trouver la limite de la VM WordPress.
Les résultats bruts de JMeter : nombre de requêtes 935 664 avec 7% d’erreur.

La légende des abscisses indique le jour 10 (Février) suivi de l’heure.
Les 80 threads sont atteints à 08h27. C’est à partir de ce moment qu’on atteint le maximum de la charge jusqu’à 08h37.

Les métriques de la VM sont les suivantes. La granularité de l’outil de graphes Munin, utilisé pour ces tests est de 5 minutes.

Il faut noter l’amélioration du maximum. On est à 360 requêtes/s ce qui prouve que la VM avec encore des ressources. On a augmenté de plus de 60% pour une augmentation de 100% du nombre de threads. Ce qui indique qu’il y a probablement une contention, sinon on aurait aussi fait 100% de requêtes/s en plus !

Apache ne fait rien ou presque.

La charge de la VM n’est pas significative, il ne faut pas tenir compte des petites variations.

L’utilisation de la CPU a doublé et passe à 20%, ce qui reste faible. Ce n’est pas en calcul que la VM est limitée.

Là aussi, on a un « joli » graphe mais pas significatif. MySQL ne fait rien.

On voit la contention !!! Le maximum de débit réseau est atteint à 8h20, alors que les 80 threads sont atteints à 8h27. Ce plateau montre que la VM n’arrive pas à produire plus de pages que lorsqu’elle est soumise à 65 threads.

Les métriques coté JMeter sont les suivantes. La granularité des JMeter est de 1 minutes, c’est donc beaucoup plus précis dans notre cas que les graphes Munin.

La latence ne varie pas jusqu’à 8h20 puis elle se disperse. En fait lorsque la machine est saturée, comme on atteint une limite de débit, les latences s’allongent.

Même constat, les temps de réponse s’allongent à partir de 8h20.

Et le débit ne suit pas les threads…..

Conclusions à tirer de ce troisième test :

1. On a réussi à saturer la VM vers 65 threads.
2. La contention apparaît au niveau du réseau. La VM n’arrive pas à fournir plus de 15 Mbps.
3. Au delà de 65 threads, la VM répond, mais les temps de réponse s’allongent et elle produit des erreurs.

L’article Booster son WordPress avec Varnish 4/4 est apparu en premier sur Alain ARDITI's blog.

Alors voici les courbes des 3 tests, juxtaposées.

La courbe de gauche correspond au premier scénario avec 40 threads servis par Apache sans Varnish. Dans ce cas WordPress va récupérer le contenu des pages générées par le plugin WP Fastest Cache sur le disque puis renvoyer la page au client. Dans ce premier scénario Nginx génère le SSL et Apache renvoie les pages.

On voit lors de la comparaison que le comportement à 40 threads est perturbé car on ne trouve pas de plateau de 10 minutes. On a une décroissance des métriques qui montre qu’il y a une saturation pour servir les pages à cette fréquence. A 40 threads on est un peu au delà de ce que peut supporter la VM. Cette valeur n’est pas arrivée par hasard, c’est la conséquence de multiples essais pour trouver le point de saturation.

La CPU suit le nombre de requêtes servies par Apache qui utilise principalement la CPU. On voit la saturation à 22h30 sur la CPU. Quand on ajoute Varnish, le serveur ne travaille presque plus ! Le reste de la CPU provient d’une page dynamique du scénario qui ne peut pas être cachée par Varnish.

Avec Varnish à 40 threads, il n’y a aucune saturation. La VM sert 30% de requêtes en plus. C’est pour cette raison qu’on pousse la VM avec un test à 80 threads, qui montre un doublement de la tenue en charge par rapport à Apache tout seul. On n’a pas de doublement par rapport au scénario Varnish 40 threads, ce qui montre qu’il y a une saturation, qui se produit à 8H20 avant d’atteindre les 80 threads.

L’autre indicateur qui montre la saturation à 80 threads est le taux d’erreur des requêtes qui monte à 7%. Le serveur n’arrive plus à suivre et génère des erreurs, on voit aussi sur le graphe réseau une légère diminution du débit. En conclusion là aussi on atteint la limite de la VM avec un débit de 15,5 Mbps et 360 requêtes par secondes.

Dans le scénario, on ne récupère que les pages HTML, qui sont relativement légères, quelques Ko, sauf une qui pèse 100Ko. On imagine que si on traitait les images/CSS/JS on aurait une saturation bien plus rapide. On peut imaginer que ces éléments soient servis par un CDN qui déchargerait le WordPress. Donc notre test pourrait se rapprocher de conditions réelles si on utilisait un CDN en plus.

Par contre, que représentent 360 requêtes par seconde ?

Ca dépend de la manière dont naviguent les internautes. Est-ce qu’un internaute parcourt 5 pages du site, est-ce qu’il en parcourt une centaine, comme sur les catalogues ? Est-ce qu’il ne regarde qu’une seule page, parce qu’il arrive d’un moteur de recherche ?

A chaque site sa réalité. On va faire un petit calcul théorique sur la base d’un parcours de 5 pages par visite, un peu comme un journal, avec l’heure d’affluence autour de 9h, à l’arrivé au bureau et à 18h.

On estime que l’heure de 9h représente 20% du trafic de la journée. C’est à cette heure là qu’on atteint le débit maximal. Si on veut savoir ce que représentent nos 360 requêtes/s, on suppose que ce pic se produit pendant cette heure. Cas théorique où le serveur produirait 360 pages à la seconde sans faiblir pendant 1 heure.

En 1 heure, le site aura produit 360×3600 = 1 296 000 pages. Comme chaque internaute regarde 5 pages, on aura eu l’équivalent de 259 200 visites pendant cette heure. Cette heure représente 20% du trafic journalier, donc en 1 jour on aura eu 1 296 000 visites !

Reste à extrapoler au mois. Si on considère que le Lundi matin est le jour de pointe et qu’il représente le tiers du trafic des autres jours, en une semaine on aura eu 1 296 000 x 3 = 3 888 000 visites. Et en 1 mois, on en aura 4 fois plus, soit : 15 552 000 visites par mois !

Et tout ça servi par un WordPress sur une VM avec 1 vpcu et 500 Mo de RAM, 1 Varnish, 1 Nginx pour le SSL et un CDN pour servir les éléments statiques.

Ces chiffres sont relativement optimistes, on n’a pas de sessions, pas de commentaires, par d’éléments à rafraîchir, on est dans un cas idéal pour les performances. Néanmoins, on peut constater que lorsqu’on arrive à mettre des pages en cache, on peut arriver à des performances exceptionnelles !

Et si on n’a pas un site statique, on voit l’importance de mettre des bouts d’Ajax pour les éléments dynamiques dans des pages statiques pour pouvoir bénéficier des effets de cache. Mais bien sûr dans ces architectures, il est fondamental de vérifier qu’on a bien des éléments statiques qui ne varient pas selon l’utilisateur. Et on s’aperçoit souvent qu’il reste des petits bouts dynamiques dans les pages qui empêchent toute mise en cache et font tomber les performances malgré des infrastructures archi musclées. Dommage !

Précédent : Booster son WordPress avec Varnish 4/4

Références :
WordPress : https://wordpress.org
Varnish : https://varnish-cache.org
Munin : http://munin-monitoring.org
JMeter : https://jmeter.apache.org

L’article Booster son WordPress avec Varnish 5/4 est apparu en premier sur Alain ARDITI's blog.