Varnish notes

varnish.md

Varnish

Intro

• "HTTP reverse proxy" => server-side HTTP cache => HTTP accelerator

client 1    --- GET foo --->    Varnish    --- GET foo --->    web app    (cache miss)
client 2    --- GET foo --->    Varnish    (cache hit)

• Linux-only, OSS, *nix philosophy (command tools)
• configurable via DSL langage "VCL"
• 2 niveaux de service payant :
  • "Silver" : support (nombre de requêtes limité) et outils+ (ex : Varnish Console) ; pris par Vidal
  • "Gold" : outils++ et prix++
• Versions
• stable release : 3
• latest : 4 (release : 2014-04-10), plus de features, plus d'utilisation CPU

Concepts de base

• hits/misses
• invalidation (expiration, forcée)
• ban: invalidation forcée
• transient objects: qui ont une durée courte aka short-lived objects, c-a-d inférieure à un seuil configurable, stockés dans un espace mémoire distinct
• grace period: période pendant laquelle un objet périmé est retourné
• object key: configurable, par défaut : hash(req.http.host, req.url).
• time-to-live: durée de vie d'un objet avant expiration

Outils de base

man est ton ami ! :-)

varnishstat monitoring: affichage de la valeur courante des compteurs (hits, misses, etc...)

exemple :

	Hitrate ratio:        1        1        1
	Hitrate avg:     0.9986   0.9986   0.9986

	       56872         0.00        20.29 client_conn - Client connections accepted
	       56978         0.00        20.33 client_req - Client requests received
	       56796         0.00        20.26 cache_hit - Cache hits
	          82         0.00         0.03 cache_miss - Cache misses
	          29         0.00         0.01 backend_conn - Backend conn. success
	         153         0.00         0.05 backend_reuse - Backend conn. reuses
	          27         0.00         0.01 backend_toolate - Backend conn. was closed
	         182         0.00         0.06 backend_recycle - Backend conn. recycles
	         114         0.00         0.04 fetch_length - Fetch with Length

varnishhist monitoring: Hits/misses par durée de requêtes

exemple :

	                      #
	                      #
	                      #
	                      #
	                      ##
	                     ###
	                     ###
	                     ###
	                     ###
	                     ###
	                  |  ###
	                  |  ###
	                | |  ###
	                |||| ###                    #
	                |||| ####                   #
	                |##|#####   #           #   #  # #
	+-------+-------+-------+-------+-------+-------+-------+-------+-------
	|1e-6   |1e-5   |1e-4   |1e-3   |1e-2   |1e-1   |1e0    |1e1    |1e2

varnishsize monitoring, affichage du graphe de hits/misses par taille d'objet

ex:

	1:10, n = 304


	                                                         |
	                                                         |
	                                                         |
	                                                         |
	                                |     |  | |  |          |
	                                |     |  | |  |          |
	                                |     |  | |  |          |
	                                |     |  | |  |          |
	+-----------------+-----------------+-----------------+-----------------+-----------------+-----------------+-----------------
	|1e1              |1e2              |1e3              |1e4              |1e5              |1e6              |1e7

varnishtop monitoring, affichage des resources (URLS, HTTP codes, HTTP header, etc...) les plus demandées ()

ex:

 # top URLs (print once):
 varnishtop -i RxURL -1
  5552.00 RxURL /rest/api/products?q=test
  5533.00 RxURL /
  5524.00 RxURL /rest/api/product/69957
  5521.00 RxURL /rest/api/vmps?q=pac
    33.00 RxURL /rest/application.wadl
     6.00 RxURL /rest/api/product/8005

varnishtest Test de config VCL

Permet de mocker des clients et des backends via DSL dédié

Exemple de test unitaire pour vérifier que notre config permet de positionner l'entête "Accept-language":

#!/usr/bin/varnishtest

varnishtest "language"

server s1 {
       rxreq
	   expect req.http.Accept-Language == "fr_FR"
       txresp
	   
       rxreq
	   expect req.http.Accept-Language == "es_MX"
       txresp
} -start

varnish v1 -arg "-p vcl_dir=${pwd}/src/main/varnish" -vcl {
        import std;

        backend api_vidal_fr {
                .host = "${s1_addr}";
                .port = "${s1_port}";
        }

        backend restnews_vidal_fr {
                .host = "${s1_addr}";
                .port = "${s1_port}";
        }

        backend licence_vidalid_vidal_fr {
                .host = "${s1_addr}";
                .port = "${s1_port}";
        }

        acl purge {
                "localhost";
        }

        include "policy.vcl";
} -start

client c1 {
	txreq -hdr "Host: api.vidal.fr"
	rxresp
	
	txreq -hdr "Host: api-mx.vidal.fr"
	rxresp
} -run

Usage Vidal

• 1 seule config pour 3 backends : REST API, news, vidal-id (licences)
• TTL différents suivants resources: fastdoc : 24 h, news : 15 min, etc...
• positionnement forcé du HTTP header 'Accept-Language' (request) en fontion du host name

Bonnes pratiques

• omettre les lignes VSL venant du fichier par défaut
• éviter les return (ex: sub_vcl_fetch)
• taxonomy pouvoir invalider des objects par groupes
• positionner le TTL dans l'appli (backend), pas dans Varnish
• si requêtes non modifiées et non cachées (ex: vidal-id), utiliser "pipe"
• tests : regrouper les testes similaires pour éviter l'overhead du démarrage de l'instance
• utiliser include VSL : ex:

main.vsl
 ->  backends.vsl       (peut être mocké pour les unit tests)
 ->  cache-policy-api.vsl
 ->  cache-policy-news.vsl
 ->  cache-policy-vidalid.vsl

But: lisibilité + testabilité

Tricks

• Par défaut, Varnish ajoute le response HTTP header "X-Varnish=[request id] <cache writer's request id>", donc par exemple :

"X-Varnish=222 111": cache hit
"X-Varnish=222": cache miss

• Pour valider la config / comparer avec la config existante :

varnishd -Cf /etc/varnish/default.vcl