5 cose da considerare quando si migra da Varnish 3 a Varnish 4

Varnish Cache 3.0 (il progetto open source) e´ stato rilasciato nel 2011 mentre Varnish Cache 4.0 e` arrivato nel 2014. Dopodiche´ e` arrivato Varnish Cache 4.1.x ed ora anche Varnish Cache 5.0.

Varnish Cache 3.0 e´ arrivato alla sua EOL, quindi non e´piu´ aggiornato/mantenuto. Questo significa che se state ancora utilizzando la versione 3.0 dovete decisamente aggiornarvi e questo blog post e´per voi.

Il motivo per cui spiego i cambiamenti fra Varnish 3.0 e 4.0 e´perche´ fra queste due versioni sono avvenuti cambiamenti molto importanti che hanno visto un totale rifacimento dell’architettura di Varnish Cache. Se capite cose e´successo fra la versione 3.0 e la versione 4.0, allora sarete anche in grado di capire tutte le versioni piu´giovani della 4.0.

• Threading model:  in Varnish Cache 3.0 vi era un unico thread per ogni client, il thread in questione si occupava di prendere il contenuto dalla cache o dai server e di consegnarlo al client.
  In Varnish 4.0 ci sono due threads: uno per il client e uno per il backend/server. Questo cambiamento ha portato ad un’enorme guadagno dal punto di vista della performance dando la possibilita’ di servire del contenuto un po’ “vecchio” al cliente mentre il contenuto piu’ nuove viene preso da un “background fetch”.
• VCL: come risultato importante del nuovo threading model, a partire da Varnish Cache 4.0 nel VCL workflow ci sono routines che sono strettamente riferite al backend thread:
  • vcl_backend_fetch
  • vcl_backend_response
  • vcl_backend_error
• Grace behaviour:  prima di Varnish 4.0 tutti i backends dovevano essere considerati “sick” prima che Varnish potesse usare un oggetto “stale”(raffermo) per completare una richiesta da un client. A partire da Varnish 4.0 e’ presente il supporto nativo per implementare il concetto di stale-while-revalidate che significa che Varnish, se non trova contenuto “fresco”, allora servira´contenuto un po’ stale(raffermo).
  Ecco il VCL:
  sub vcl_hit {
if (obj.ttl >= 0s) {
# fresh object present in cache
# normal hit
return (deliver);
}# We have no fresh objects. Let’s look at the stale ones
  if (std.healthy(req.backend_hint)) {
  # Backend is healthy. Limit age to 10s
  # A background fetch is triggered to fetch a fresh object.
  if (obj.ttl + 10s > 0s) {
  set req.http.grace = “normal(limited)”;
  return (deliver);
  } else {
  # No candidate for grace. Fetch a fresh object.
  return(fetch);
  }
  } else {
  # backend is sick – use full grace
  # a background fetch is triggered to try to fetch fresh content
  if (obj.ttl + obj.grace > 0s) {
  set req.http.grace = “full”;
  return (deliver);
  } else {
  # no graced object.
  return (fetch);
  }
  }
  }
• Directors: In Varnish Cache 3.0 una “director” non era altro che un gruppo di backends da cui Varnish poteva scegliere per prendere il contenuto da inserire in cache.
  A partire da Varnish 4.0, per rendere tutta la logica intorno al modo di selezionare backend piu´semplice,  il concetto di director e´stato spostato in un VMOD(Varnish Module) cosi´puoi avere la liberta´di sviluppare la tua personale logica in base a cui Varnish scegliera´i backend.
• Purge: In Varnish 3.0 vi era la parola chiave “purge” per eliminare contenuto in cache. Ora, a partire da Varnish 4.0 la parola purge e´stata ritirata, ma e´invece possibile invalidare elementi cache via VCL:
  sub vcl_recv {
…
if (req.method == “PURGE”) {
return(purge);
}
}Piu´informazioni:https://www.varnish-software.com/plus/varnish-cache-plus/