Cenni di Caching applicato a Plone

Potete servire decine di pagine al secondo con il vostro portale Plone configurando plone.app.caching e facendo un po' di attenzione alla messa a punto.

L’esperienza di navigazione di un sito web può essere qualcosa di estremamente noioso, se i tempi di risposta ai nostri clic sono lenti, tanto da indurci ad abbandonare il sito stesso.

Per evitare ciò si lavora su più fronti, ad esempio snellendo le pagine inviate, sfoltendo le risorse usate (css e javascript, in testa), adottando immagini sempre meno pesanti, facendo uso di AJAX per aggiornare solo pezzi di pagina.

Caching HTTP

Tra i vari modi di velocizzare i nostri siti ce n’è uno molto efficace, e a volte poco praticato, per mancanza di tempo o di competenze: il caching HTTP.

Se non ne sapete ancora nulla, iniziate con questa lettura molto interessante: http://www.mnot.net/cache_docs/ (leggetelo!!)

Web Cache

Un client web, tipicamente il browser, non chiede nuovamente al server che la produce una certa risposta, se quella ottenuta un attimo prima è ancora considerata valida.

Un server di cache si colloca tra i client che operano le richieste e i server che producono le risposte, e memorizza copie delle risposte da poter restituire a chi ne fa nuova richiesta, senza dover  interpellare i server che le avevano prodotte.

In questo modo è possibile ridurre i tempi di latenza, facendo apparire i siti più veloci, come pure diminuire il traffico di rete, rendendo accettabile anche la navigazione senza banda larga.

Controllare le cache: freschezza e validazione

Le cache decidono se riusare una risorsa che hanno già disponibile o chiederne una nuova versione in base a una serie di regole. I casi più comuni sono i seguenti:

  1. se gli header nella risposta dal server dicono alla cache di non salvare una copia, la cache non lo farà.
  2. se la richiesta è in HTTPS, la cache non salverà una copia
  3. una rappresentazione in cache è considerata “fresca”, cioè pronta da essere inviata ai client senza dover controllare sul server originale, se:
    • ha un tempo di scadenza o altri header per il controllo della “age” (anzianità della rappresentazione), e risulta ancora nel periodo di “freschezza”,
    • se la cache ha ottenuto la rappresentazione di recente, e risulta modificata relativamente molto prima.
  4. rappresentazioni “fresche” sono servite direttamente dalla cache, senza controllare sul server originale
  5. se una rappresentazione è vecchia, il server originale sarà interpellato per invalidarla, o dire se la copia in cache è ancora buona.

Se una risposta non presenta nessun elemento di validazione (es. ETag o header Last-Modified), né esplicite informazioni di freschezza, normalmente viene considerata non buona per la cache.

Insieme, freschezza e validazione sono i modi più importanti con cui una cache lavora con i contenuti.

Una rappresentazione fresca verrà servita istantaneamente dalla cache, mentre una rappresentazione validata eviterà di inviare nuovamente una intera rappresentazione, se nel frattempo non è cambiata.

Quindi il controllo della cache normalmente si gioca manovrando su alcuni header specifici, opportunamente descritti dal protocollo HTTP 1.0 e 1.1 (cfr. http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html)

Gli header più usati

Expires - indica la data di scadenza di una rappresentazione.

Last Modified - indica la data di ultima modifica di una rappresentazione

Cache-Control - contiene informazioni per stabilire freschezza e validità della rappresentazione (maxage, s-maxage, must-revalidate, etc.)

ETag - contiene informazioni per stabilire la validità della rappresentazione (cfr. http://www.infoq.com/articles/etags)

Vary - contiene informazioni per stabilire la validità della rappresentazione (cfr. http://mark.koli.ch/2010/09/understanding-the-http-vary-header-and-caching-proxies-squid-etc.html)

Cosa fare quando il server è Plone

A questo punto è piuttosto chiaro come il controllo degli header di caching sia cruciale per una esperienza fluida e corretta dei nostri siti. Sì, perchè data la voglia di velocità di fruizione, il rischio è quello di far vedere copie cache indesiderate ai nostri utenti, per eccesso di zelo o di mal configurazione.

Plone è un CMS piuttosto complesso, e ogni richiesta impiega mediamente tempi di calcolo lunghi, a differenza dei tempi di risposta molto stretti di un server di cache. Nonostante ciò, molte delle richieste rivolte a Plone potrebbero essere “evitate”, a ben guardare:

  • file e immagini del tema statico - il mondo di diazo e plone.app.theming: potrebbero avere freschezza e data di scadenza molto lunghi, giorni o settimane;

  • file e immagini dell’interfaccia utente - quello che vive in portal_skins, ad esempio: anche questi potrebbero avere freschezza e data di scadenza piuttosto lunghi;

  • file e immagini dei contenuti - generati con i content type di Plone: questi potrebbero essere modificati dai redattori, ma dargli una validità di qualche minuto/ora aiuta comunque a non stressare i server con richieste spesso inutili;

  • viste sui contenuti - applicate ai content type standard: pagine, notizie, etc.: queste sono frequentemente modificate dai redattori, quindi il caching dovrebbe essere molto più blando o del tutto nullo, e basato sulla data di ultima modifica;

  • viste sulle cartelle - applicate agli oggetti che offrono liste di altri oggetti: queste sono tra le più difficili da gestire a livello di caching, perchè una data di ultima modifica da utilizzare per operare la validazione non esiste.

Vi vengono in mente altre situazioni? Nei casi base probabilmente no. Dunque, riuscire a raggruppare le richieste secondo queste regole e applicare gli header di caching di conseguenza non sarebbe male. :)

Siate felici perchè, se questo vi piace, è esattamente il modo di funzionare di plone.app.caching:

Regole plone.app.caching

In base alla richiesta, plone.app.caching seleziona la regola più opportuna, e applica la policy di caching associata.

In particolare le policy di base sono: strong, moderate, weak, no cache, chain (cfr. http://pypi.python.org/pypi/plone.app.caching#default-cache-operations)

Configurazione di Plone.app.caching

Quando si installa il pacchetto plone.app.caching, dal tab “Importa le impostazioni” è possibile scegliere delle configurazioni pre-definite, specificando in particolare se si sta usando un server di caching come Varnish o no.

Usare un server di caching è fondamentale per siti ad alto numero di accessi, in quanto scarica notevolmente il server Zope dalle richieste meno significative, e garantisce tempi di risposta molto più alti. Questo pone anche delle problematiche, in particolare la necessità di intervenire su un servizio extra-zope per invalidare eventuali rappresentazioni non più valide. Il trucco consiste spesso, infatti, nell’indicare al Browser un tempo di scadenza immediato, e nello specificare un tempo di scadenza più lungo sul server di caching (s-maxage). In questo modo il rischio di avere contenuti vecchi sui browser dei nostri utenti è nullo, ma il carico delle risposte è comunque sbilanciato sul server di caching, molto più controllabile a livello di invalidazione manuale.

Per il resto, tramite il tab “Impostazioni dettagliate” si possono controllare i parametri delle policy di caching associate alle varie regole, andando ad esempio ad impostare i vari ETag che permettono di inviare agli utenti versioni corrette delle varie pagine.

Plone.app.caching offre una serie di ETag predefiniti, tra cui uno chiamato “catalogCounter”, che fornisce un numero che si incrementa a ogni nuova indicizzazione nel portal_catalog di Plone, molto utile per inviare agli utenti versioni sempre aggiornate delle viste con i listing dei contenuti.

In ogni caso, se quanto procurato da plone.app.caching di default non bastasse, è molto facile per lo sviluppatore implementare all’occorrenza i propri ETag, le proprie regole e le proprie policy.

Plone.app.caching ha diverse ulteriori prerogative, ma lascio alla ottima documentazione (cfr. http://pypi.python.org/pypi/plone.app.caching) il compito di svelare le sue varie possibilità.

Vediamo invece rapidamente in che modo possiamo capire cosa fare per rendere il nostro sito il più veloce possibile.

Come mettere a punto le cache, e non solo

Quando si usa Plone per generare i propri contenuti, Plone.app.caching è un valido punto di partenza, ma non basta.

Avere un chiaro schema dell’architettura dei servizi e delle varie policy attive, per non perdersi in mezzo ai vari header, può essere molto utile (anche varnish e il web server possono manipolare gli header).

Il tab “Network” di Firebug (http://getfirebug.com/) diventerà un vostro caro compagno di lavoro, dove andare a capire se ci sono risorse che non sono gestite come ci si aspetta, vedendo per ciascuna gli header associati.

Infine, Google Page speed (https://developers.google.com/pagespeed) - è un servizio online e una estensione per Firefox e Chrome. Fornisce un valido aiuto per capire cosa manca da sistemare, e non si limita alle problematiche di caching, ad esempio mettendo in evidenza quanto aiuterebbe una compressione gzip, come pure offrendo un pannello di controllo delle varie chiamate operate a fronte della richiesta di una pagina, dove è facile avere una idea chiara dello stato e degli header di ogni richiesta.

Buon caching a tutti!

Share this on

Share |

On same topics

Commenti

comments powered by Disqus