Info:

twitter

Ultimi commenti: Comment feed

Tags:

Sponsor:

Archivio 2018:

Gen

Archivio 2017:

Dic Nov Ott Mag Apr Mar Feb Gen

Archivio 2016:

Dic Nov Ott Ago Mag Mar Feb Gen

Archivio 2015:

Nov Ott Set Mar Gen

Archivio 2014:

Dic Nov Ott Set Lug Giu Mag Apr Gen

Archivio 2013:

Dic Nov Set Ago Lug Giu Mag Apr Feb Gen

Archivio 2012:

Dic Nov Ott Set Ago Giu Mag Apr Mar Feb Gen

Archivio 2011:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2010:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2009:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2008:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2007:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2006:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Caching

Come promesso in precedenza eccomi a parlare di codice e di come ho implementato il sistema di cache in blogoo. È diventato necessario quando il numero di commenti per post ha cominciato a superare una certa soglia: il mio ISP è molto generoso ma prevenire resta sempre meglio che curare. Senza la cache la pagina viene renderizzata ad-hoc ogni volta che viene invocata. Questo è un peccato perché buona parte dell’output restituito al browser è ‘facilmente’ sistemabile in una cache. Facilmente è tra virgolette perché gli elementi della sfida sono tanti:

  1. è interessante fare tenere nella cache sia le pagine che puntano ad un singolo post, sia le pagine che contengono più di un post (la home-page, gli archivi, le pagine per tag, ecc.), sia dei “pezzi di pagina” (gli ultimi commenti, tag-cloud, archivio, ecc.) 
  2. la cache deve gestire correttamente sia le pagine visibili solo dall’editor del blog, sia quelle visibili dagli utenti cercando di non fare confusione
  3. la cache deve essere invalidata solo quando necessario; nel dubbio se sia necessario o meno è meglio invalidare che servire contenuto “scaduto”.
  4. Se possibile è meglio invalidare solo lo stretto necessario: ad esempio la tag-cloud dovrebbe essere invalidata solo in caso di modifica/aggiunta di post o di categorie
  5. la cache deve essere invalidata quando del contenuto “post-datato” diventa automaticamente visibile

Analizzando la questione a tavolino sono emerse un paio di cose. Gli eventi invalidanti sono in generale 2: l’aggiunta/modifica di un commento, l’aggiunta/modifica di un post. Tutto il resto, ad esempio il punto 5., può essere ricondotto ad uno dei due casi. L’aggiunta/modifica di un post poi può a sua volta generare due tipi diversi di eventi: un evento che invalida la “collezione dei post” ed un evento che invalida il singolo post. Ad esempio un commento sul post X invaliderà la collezione dei post (in quanto tale collezione potrebbe mostrare il numero di commenti per quel post), invaliderà il post X ma non il post Y. Per cui se un utente clicca sul post Y dopo che è stato scritto un commento su un altro post, si ritroverà il post servito dalla cache.

L’invalidazione poi tiene conto di diversi fattori. Ad esempio cancellare un commento moderato non deve avere effetti sulla cache in quanto non visibile a priori. Stessa cosa per la pubblicazione di un draft e così via.

Fatto questo, il resto diventa un gioco da ragazzi: ogni elemento inserito nella cache porta in dote la sua lista di dipendenze. Un componente separato da me battezzato CacheManager si mette in ascolto dei vari eventi (creazione/modifica/cancellazione dei post/commenti) e in base allo stato della cache, al tipo di evento e le condizioni a contorno (era un draft? è diventato un draft? c’è qualche articolo postdatato in coda?) invalida zero, una o più dipendenze causando la rimozione a cascata di tutti gli elementi da esso dipendenti. L’unica accortezza è gestire correttamente la “scadenza” della cache: nel momento in cui del contenuto viene prelevato dalla cache va confrontata la data di “prelievo” con la data di "scadenza" e se la cache è scaduta la data di scadenza viene ricalcolata, ciò che va invalidato viene invalidato, e tutto il resto prosegue come prima.

Infine un’ultima nota: avrei potuto tenere una cache separata per gli editor, però mi è sembrato più saggio fare in modo che il contenuto fosse manipolato a posteriori.

I risultati sono sorprendenti: il post da quattro mucche caroline e 428 (!) commenti viene renderizzato in 5 secondi senza cache, appena 192 millisecondi se il post è già presente in cache. Considerato il tempo sprecato (mezza giornata circa) ed i risultati ottenuti, direi che ne è valsa davvero la pena.

Nota aneddotica: il baco più antipatico, l’Heisenbug che faceva sparire i commenti di Daniele B. dalla cache, era dovuto al fatto che il mio ISP usa un sistema arcano di load-balancing per cui le richieste al sito www finivano solo alcune volte per essere eseguite dallo stesso server che gestisce il sito senza www. Che poi non ho ancora capito perché a livello di hosting, visto che i due siti puntano allo stessissimo contenuto, sono configurati come due siti separati: individuato il problema, la soluzione è stata semplice e immediata. Redirect 301 di tutte le richieste www al sito principale. La cache è sempre sincronizzata e tutti i paperi (?) vissero felici e contenti.

-quack

Potrebbero interessarti anche:
Commenti (4):
1. Daniele B.
sabato 29 novembre 2008 alle 9:14 AM - unknown unknown unknown
   

Vedi, riesco perfino a farti lavorare!

   
2. gino
sabato 29 novembre 2008 alle 11:12 AM - unknown unknown unknown
   

quello che non capisco è perchè la piattaforma non abbia già integrata al suo interno un sistema di caching così poi dovevi solo ed esclusivamente personalizzarlo. in questo modo hai dovuto reinventare la ruota.

btw, che ne dici di un post su cui spieghi i pregi e i difetti di questa piattaforma rispetto ad una su php? naturalmente io prenderei wordpress dato che è la più famosa

   
3. Edward
sabato 29 novembre 2008 alle 12:30 PM - unknown unknown unknown
   

[puff smoker mode ON]

@ Gino:

Blogoo e' una piattaforma ASP.NET creata ad hoc da qualcuno which shall be nameless : l'autore aggiunge funzionalita' man mano che le ritiene necessarie, ergo Paperino ci deve sempre mettere mano oppure fare pressioni sull'autore, che e' molto impegnato e risponde quando puo'; in pratica Paperino ha il diritto/dovere di mantenere il codice: IMNSHO ormai lo conosce a memoria. Il caching mancava ma e' diventato indispensabile solo quando i commenti hanno superato una certa dimensione ed il tempo di caricamento e' diventato inaccettabile.

Pregi e difetti? Fra i primi la piu' importante e' la certificazione "It works by accident", con la speranza di raggiungere in futuro quella "It works on my machine" ; fra i secondi il mancato testing con l'implementazione ASP.NET di Mono (questi programmatori moderni! D'altronde l'autore ha a malapena il tempo per controllare il codice, figuriamoci testarlo su OS con cui litiga sempre ...).

 

Edward

[puff smoker mode OFF. But do you truly trust me anyway?]

   
4. Paperino
sabato 29 novembre 2008 alle 11:07 PM - unknown unknown unknown
   

@Edward: bello il tuo commento.

@Gino: la piattaforma me la son scritta da 0 dopo averne provate davvero tante: blogspot, wordpress (versione hosted), DasBlog, DBlog, ThinkJot e Community Server. Ho anche guardato BlogEngine, SubText e Graffiti, ma ognuna con tanti pregi ma difetti insormontabili. Quasi tutte usano PHP/Asp.Net come view engine che rende la personalizzazione del template davvero complicata. Mi son detto che chi fa da sé impara qualcosa.

Ho promesso di renderla disponibile in qualche maniera non appena assume una forma "stabile". Dall'esterno è molto stabile, ma la gestione pecca di alcune piccole mancanze per definirla persino una beta. Però sono già 5 i siti/blog che girano su una alpha. Con qualche glitch durante l'installazione ma intanto girano...

   
Lascia un commento:
Commento: (clicca su questo link per gli smiley supportati; regole di ingaggio per i commenti)
(opzionale, per il Gravatar)