Sysadmins will want VarnishMaintenance.

Migrer un site vers Varnish (cache.koumbit.net)

• Un site Drupal 6 doit être sur une plate-forme Pressflow pour supporter Varnish (comparaison entre Pressflow et Drupal).

• Si le module Boost est activé, alors le désactiver. Si le site est dans Aegir, faire un verify après avoir désactivé boost pour retirer les rewrite rules.

• Si le module Domain Access est activé, alors lire Domain Access & Varnish Caching et Varnish together with Expire and Domain Access modules.

Procédure rapide

• À l'aide de Munin, vérifier la quantité de requêtes que reçoit un site web. On voudrait passer dans Varnish les sites ayant une moyenne supérieure à 100.

  • ceres : http://stats0.koumbit.net/koumbit.net/ceres.koumbit.net/apache_hits_per_domain.html

• Ouvrir un ticket RT pour communiquer avec le client et pour garder une trace à l'interne.

• Pour toutes les versions de Drupal, afin de faire suivre l'adresse IP du client d'origine dans la soumission de formulaires et/ou de filtrage du spam, ajouter ces lignes au fichier local.settings.php:

  <?php
  
  // cache.koumbit.net, cache0.koumbit.net, cache1.koumbit.net
  $conf['reverse_proxy'] = true;
  $conf['reverse_proxy_addresses'] = array('199.58.80.78','199.58.80.104','199.58.80.105');

• Pour forcer la cache sur le site drupal, ajouter ces lignes au fichier local.settings.php:

  <?php
  
  // External caching mode for Varnish.
  $conf['cache'] = 3;
  // same as Page cache maxiumum age
  $conf['cache_lifetime'] = 3600; // 1h
  $conf['page_cache_max_age'] = 3600; // 1h

  ou bien ce code plus souple:

  <?php
  
  global $conf; unset($conf['cache']);

  • puis configurer Drupal par l'interface web:

  • Drupal 7: /admin/config/development/performance

  • Drupal 6: /admin/settings/performance

  • Cache mode: External (Drupal 6 seulement, dans drupal 7 choisir le mode le plus élevé)
    Le mode de caching externe peut demander de désactiver des modules qui ne supportent pas le caching aggressif. Il est possible de laisser certains modules actifs (exemple: i18n), mais certaines fonctionnalités sont, par définition, incompatibles avec le caching aggressif. Exemple: une page d'accueil différente selon la langue; solution: un splash page.

  • Minimum cache lifetime: 15 min.
    Sinon au moins 1 min. Does not affect varnish!

  • Page cache maximum age (Drupal 6) / Expiration of cached pages (Drupal 7): 30 min.
    Sinon au moins 1 min.
    À noter que Varnish va respecter les réglages de lifetime des cache de Drupal. Il est donc utile de régler une cache, même si le lifetime est de seulement une minute.

• Modifier les DNS pour pointer le domaine vers le serveur Varnish:
  • Si le DNS est géré par Koumbit dans AlternC, pointer le domaine vers le IP 199.58.80.78.
  • Si le client gère ses DNS, lui demander de pointer le domaine vers le cname cache.koumbit.net.
• Tester (voir section plus bas).
• Aviser le client de la nouvelle fonctionnalité.

http://drupal.stackexchange.com/questions/83315/difference-between-minimum-cache-lifetime-and-expiration-of-cached-pages

Procédure avec benchmark avant la mise en prod

L'idée est d'utiliser un domaine différent du site en production qui servira à tester Varnish.

• Créer un domaine varnish.exemple.org qui pointe vers cache.koumbit.net.
• S'assurer que varnish.example.org soit dans la liste d'alias du site dans Aegir et que cet alias ne redirige pas vers le domaine principal (le nom du site aegir).
• Faire un benchmark de varnish.example.org (voir les tests ci-dessous).
• Lorsque satisfait, pointer les DNS du domaine principal vers le serveur Varnish (voir la procédure rapide plus haut).

Tester

• Si les tests ci-dessous ne fonctionnent pas tout de suite, c'est peut-être la propagation DNS qui ne s'est pas faite encore. Une façon de tester serait de définir le domaine dans son /etc/hosts local.

• Pour vérifier si l'échec des tests dépend de la propagation DNS:

  dig www.exemple.org +short
  
  dig @ns1.koumbit.net www.exemple.org

• Utiliser le site http://www.isvarnishworking.com/ pour tester Varnish sur une URL. Lien mort!

• Vérifier l'entête qui doit contenir les lignes suivantes et l'âge qui doit être supérieure à zéro et augmenter d'une fois à l'autre. C'est le temps en second de l'âge de la cache pour cette page.

  X-Varnish: 425187551 425175452
  Age: 28672
  Via: 1.1 varnish

  Pour ce faire, utiliser l'une de ces commandes:

  • wget -S http://www.exemple.org/ --delete-after

  • curl -I http://www.exemple.org/

    $ curl -I http://monsitedansvarnish.com/
    HTTP/1.1 200 OK
    Server: Apache/2.2.15 (Debian)
    X-Powered-By: PHP/5.2.6-1+lenny16
    Cache-Control: public, max-age=43200
    Last-Modified: Fri, 06 Sep 2013 09:05:32 +0000
    Expires: Sun, 11 Mar 1984 12:00:00 GMT
    Vary: Cookie,Accept-Encoding
    ETag: "1378458332"
    Content-Type: text/html; charset=utf-8
    Content-Length: 33341
    Date: Fri, 06 Sep 2013 15:45:30 GMT
    X-Varnish: 637648402 637551262
    Age: 23997
    Via: 1.1 varnish
    Connection: keep-alive

  • Il est possible de tester directement sur le serveur Varnish avec curl -x http://cache0.koumbit.net:80/ -I http://www.exemple.org/.

• ab -c 1 -n 100 donne de meilleurs résultats que le site sans Varnish. Il est possible que les résultats ne varient pas beaucoup si la bande passante du site de test est insuffisante (exemple: derrière un DSL, ce n'est pas suffisant).

• Sur le serveur Varnish, vérifier varnishstat. Le nombre de cache misses ne devrait pas augmenter, à moins qu'il y ait d'autre traffic. On peut aussi regarder varnishlog -b pour voir quelles requêtes qui vont au backend.

URL

Statistiques du serveur Varnish de Koumbit:

• http://cache.koumbit.net/

• http://stats0.koumbit.net/koumbit.net/cache0.koumbit.net/index.html

• http://stats0.koumbit.net/koumbit.net/cache1.koumbit.net/index.html

Utiliser Varnish pour un site sur HAG

Préparer la conf sur les serveurs de caching

• éditer le fichier de configuration de varnish: site/profile/files/varnish/koumbit/default.vcl

• ajouter une condition afin que les requêtes envoyées vers le domaine pointent vers le bon backend côté HAG

  • choisir hag.backend() pour php5.6 ou hag_73.backend() pour php7.3

  • mettre en commentaire la date à laquelle le site a été ajouté

elseif (req.http.host ~ "^(.*\.)?domaine.tld$") {
    # Configured on YYYY.MM.DD to alleviate pressure on hag webnodes
    set req.backend_hint = hag_73.backend();
  }

• pour un site en https, éditer les hieradata de hector pour ajouter le site à profile::apache::externally_cached_sites (le certificat doit exister sur hector):

profile::apache::externally_cached_sites:
  domain.tld:
    cluster: cache.koumbit.net
    tls_cert: '/var/alternc/letsencrypt/live/domain.tld/fullchain.pem'
    tls_key: '/var/alternc/letsencrypt/live/domain.tld/privkey.pem'

Rouler puppet sur hector (le cas échéant), puis cache0 et cache1.

Pointer le site vers le serveur de caching

• dans alternC, modifier le domaine et choisir " Varnish accelerator (experimental)" dans les options avancées
• s'il s'agit d'un site en Wordpress / https, ajouter ceci au wp-config.php afin d'éviter une loop de redirection:

define('FORCE_SSL_ADMIN', true);
// in some setups HTTP_X_FORWARDED_PROTO might contain 
// a comma-separated list e.g. http,https
// so check for https existence
if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false) {
  $_SERVER['HTTPS']='on';
}

Vérifier que le site réponde correctement. S'il est en https, s'assurer que la redirection se fait bien et que le certificat est correctement envoyé. Un curl en http devrait retourner quelque chose comme:

~$ curl -I domain.tld
HTTP/1.1 301 Moved Permanently
...
Location: https://domain.tld/
X-Hostname: hector.koumbit.net
...
Via: 1.1 varnish (Varnish/6.1)
...

Retirer Varnish d'un site

Pour désactiver Varnish et revenir à une configuration normale:

• Pointer le domaine vers le serveur sur lequel se trouve le site.
• Drupal 6: remettre le mode de caching à "normal" dans "/admin/settings/performance".
• HAG: retirer toute trace du domaine dans puppet - un grep du domaine ferait l'affaire, mais vérifier notamment:

  • site/profile/files/varnish/koumbit/default.vcl

  • data/node/hector.koumbit.net.yaml (si ssl)

Troubleshooting

• use curl -I to test the headers of the site. you want to get rid of Set-Cookie, Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0, Pragma: no-cache and similar evil headers

• disable DrupalBoost, which involves disabling the module and reverifying the site in aegir, or removing the boost rewrite rules from the .htaccess in other setups

Modules that break caching and how to fix them

• CiviCRM

  • https://pressflow.atlassian.net/wiki/display/PF/Modules+that+break+caching,+and+how+to+fix+them

  • https://drupal.org/node/2061481

• Global Redirect

• Views Slideshow: Start slideshows on last viewed item

Purger la cache de varnish

Comme utilisateur, il est impossible de purger la cache de varnish. Seulement les sysadmins peuvent faire cette opération, par défaut (voir VarnishMaintenance#Flusher_la_cache_de_Varnish pour cela).

La bonne procédure est de réduire le temps de vie de la cache *avant* de faire des changements. Réduire le réglage Expiration of cached pages avant de faire des changements au site, attendre la durée de temps qui était présente avant de faire les changements, faire les changements puis les changements devraient être déployés après la durée de temps choisie.

Exemple:

1. Expiration of cached pages avant: 3h

2. mettre 5 minutes
3. attendre 3 heures
4. faire le changement
5. attendre 5 minutes pour vérifier que le changement est bon
6. retourner à l'étape 4 si d'autres changements sont nécessaires

7. remettre le Expiration of cached pages à la valeur originale

(Pour une bonne explication des différents paramètres de cache, voir ce post.)

Il est également possible d'automatiser la purge de la cache varnish telle qu'opérer par les sysadmins avec le module varnish, mais ceci demande un accès extérieur à l'interface d'administration, généralement avec un mot de passe. Le serveur Varnish doit doit donc être modifié pour permettre ce genre d'opération. De plus, en permettant l'accès à l'interface d'administration de Varnish, on donne des accès administrateur au serveur varnish, permettant par exemple d'arrêter le serveur complètement où de purger toute la cache, donc un enjeu de sécurité grave. Ceci n'est donc pas permis sur les serveurs partagés de Koumbit.

Meilleure méthode, recommendée

Le module purge est beaucoup plus flexible car il utilise la méthode plus portable et sécuritaire PURGE pour indiquer à Varnish (mais aussi à Nginx, Squid, etc) de retirer un élément de la cache qui a été modifié. Ceci permet d'indiquer à varnish de conserver les éléments en cache pour plusieurs semaines pour réduire à un stricte minimum les requêtes au serveur web "backend" sans que des modifications au contenu ne subissent de délai d'affichage.

Par contre cette méthode ne permet pas l'authentification (seulement besoin d'envoyer une requête de type PURGE pour une URL en particulier pour enlever un élément de la cache, sans vérification). Elle n'est donc pas permise pour les environnements partagés, car elle permet de purger la cache d'autres sites.

References

Drupal is tricky to cache. A basic performance optimisation job should be done on the site even before putting it in Varnish, see the DrupalPerformance guide.

Drupal-specific caching issues

A good start is those indymedia docs.

• Timestamp check (D7)

• X-Forwarded-Proto support (D7)

• ip_address still buggy (fixed in D6)

• Drupal supports disabling anonymous sessions (D7). For D6 you can use no_anon (no module yet for D5)

• better caching for reverse proxies Varnish config (D7) (D6 port)

• reverse proxy support for Drupal.org (D6 backport of the last two)

Other references and alternatives

• High performance group

• Drupal caching, speed and performance

• boost

• no_anon

• Integrating with Varnish

• Varnish Configuration Language (VCL)

• http://simpleritsolutions.com/drupal/mollom/proxyservers

CategoryGuide