La prossima major release di Varnish è finalmente in dirittura d'arrivo, la prima beta arriverà fra pochi giorni, seguita in tempi brevi dal rilascio pubblico.
Visto che al momento le informazioni in italiano sono poche per non dire inesistenti, nei prossimi giorni pubblicheremo qualche appunto su cosa vi potete aspettare da Varnish 3.0.
Ottimizzazioni gzip
La funzionalità che aspettavo con più ansia: nella nuova versione coesistono senza problemi out of the box, e si comportano esattamente come ci si può aspettare. Se però vi serve più controllo, sono state aggiunte delle direttive per controllare compressione e decompressione delle risposte.
Se vi interessano i dettagli tecnici:
In Varnish 2 ESI interagiva male con le risposte con encoding gzip, col risultato che era necessario disabilitare gzip dal backend--ammesso che il vostro carico ve lo consentisse. Peggio ancora, la conseguenza è che era Varnish a sua volta inviava i contenuti di risposta non compressi, ed era quindi necessario mettere davanti a tutto un ulteriore proxy per comprimere.
In Varnish 3 tutto il processo è stato ridisegnato e ottimizzato: Varnish di default chiede al backend il contenuto compresso; se il client non supporta gzip (e sono pochi) lo decomprime. La copia cachata è solo quella compressa, e questo si traduce anche in più oggetti a parità di cache, che non guasta.
ESI e gzip
Il caso ESI è più complesso, perché Varnish deve gestire la possibilità di documenti non compressi inclusi in pagine compresse e viceversa. La nuova implementazione gestisce questi casi bene, ed è anche molto ben pensata e realizzata.
Ogni documento su cui ESI è abilitato viene temporaneamente decompresso quando viene ricevuto dal backend, e Varnish genera del bytecode di controllo che tiene traccia della posizione esatta dell'include. In seguito quando è il momento di servire la pagina è possibile semplicemente concatenere i pezzi.
Qualcosa di questo tipo:
Contenuto originale:
<html>
....
<esi:include src="include1"/>
...
<esi:include src="include2"/>
...
</html>
Viene salvato in memoria come:
[parte 1, compressa]
[bytecode che indica la presenza dell'include di "include1"]
[parte 2, compressa]
[bytecode che indica la presenza dell'include di "include2"]
[parte 3, compressa]
Al momento di un hit:
[parte 1, compressa]
[risultato della richiesta al backend di "include1", compresso]
[parte 2, compressa]
[risultato della richiesta al backend di "include1", compresso]
[parte 3, compressa]
La parte importante è che il risultato finale non ha bisogno di essere decompresso e ricompresso: gzip supporta una modalità per cui tra una "parte" e l'altra è sufficiente inviare un comando di reset. Furbo, no?
Per approfondimenti e altre informazioni:
