due chiacchiere

La cache è mia e me la gestisco io

Qualche settimana fa avevo accennato agli esperimenti da scienziato matto che sto conducendo zitto zitto dietro le quinte del blog, senza farmene accorgere. In un commento a quel post, Emanuele aveva espresso le sue perplessità sull’adozione di una content delivery network per servire le pagine del blog. La sua critica era mirata principalmente all’aspetto della protezione dei dati personali: usando quel servizio, di fatto stavo regalando ai signori di Cloudflare tutte le informazioni sui miei visitatori, consentendogli di tracciarli in giro per la rete, ogni qualvolta gli ignari malcapitati visitavano una qualsiasi pagina che facesse uso dello stesso servizio (circa 7 milioni e mezzo di siti, stando ad alcune statistiche). Ammetto che, quando avevo deciso di sperimentare con questa funzionalità, né io né l’omino talebano avevamo pensato a questo risvolto. E secondo te l’amico che siede sulla mia spalla poteva lasciar cadere la cosa nel vuoto?

Così mi sono messo a fare varie prove per confrontare eventuali vantaggi in termini di prestazioni a favore di Cloudflare (benedetto sia chi ha inventato ab), nella speranza di poter convincere l’omino talebano che tutto sommato conveniva tenere attiva la CDN. Sfortunatamente i miei piani non sono andati come previsto (segno che i server di Supporthost sono più prestanti di quello che immaginavo), ed ho constatato che il guadagno netto si riduceva ad una manciata di millisecondi e qualche kilobyte. Ho provato ad ignorare la vocina petulante dell’omino talebano, ma alla fine non ho potuto fare altro che gettare la spugna e rimuovere questa configurazione, messa in atto più per lo sfizio di provarci che altro. Per la gioia di grandi e piccini, da un paio di settimane i nameserver sono di nuovo quelli di casa Supporthost, e non ci sono più intermediari sibillini pronti a vendere i dati dei siti che frequenti al miglior offerente.

la parola cache stilizzata con caratteri futuristici stampata su una scheda per computer

Si, ma che c’entra tutto questo con il titolo del post, diranno i miei piccoli lettori. Beh, l’eliminazione di Cloudflare mi ha dato l’idea per un altro esperimento (e ti pareva!). Non volendo installare plugin di caching di terze parti, ho voluto provare a scrivere un po’ di codice che implementasse un rudimentale sistema di staticizzazione delle pagine del sito. D’altro canto, ho già scritto in passato di come la penso sullo spreco di energia per tenere in vita la massa sterminata di ciarpame digitale che produciamo ogni giorno. Visto che gli articoli di questo blog non cambiano quasi mai, mi sono chiesto se non fosse meglio farne una copia statica da servire senza ulteriore uso di capacità computazionale, anziché pescarli tutte le volte dalla base di dati? Certo, ero cosciente del fatto che si trattasse di un problema complesso, sul quale migliaia di cervelloni hanno passato anni ed anni della propria vita, e non pretendevo certo di risolverlo in quattro e quattr’otto.

Alla fine ho deciso di implementare una soluzione semplice ma adeguata alle mie esigenze: gestire una cache che contiene soltanto gli articoli e la homepage, e non le categorie, gli archivi e via dicendo. Questa scelta era supportata dalle statistiche d’accesso, secondo cui homepage ed articoli rappresentano comunque circa il 95% del traffico generato dal blog. In soldoni, il mio tema cattura l’output della pagina tramite una ob_start() all’inizio, ed una ob_get_contents() alla fine (funzioni del linguaggio PHP, per chi non è pratico), e salva quel codice HTML in un file da qualche parte. Poi il server web, tramite una direttiva nell’.htaccess, quando riceve una richiesta, va a vedere se la corrispondente pagina statica esiste. Se la trova, la invia all’utente, altrimenti chiama WordPress e gliela fa generare dinamicamente:

# Homepage
RewriteCond %{REQUEST_URI} ^/$
RewriteCond %{QUERY_STRING} !.+
RewriteCond %{DOCUMENT_ROOT}/cache/index.html -f
RewriteCond %{HTTP_COOKIE} !wordpress_logged_in [NC]
RewriteRule .* /cache/index.html [L]
# All other pages
RewriteCond %{QUERY_STRING} !.+
RewriteCond %{DOCUMENT_ROOT}/cache/$1.html -f
RewriteCond %{REQUEST_URI} !^/cache/ [NC]
RewriteCond %{HTTP_COOKIE} !wordpress_logged_in [NC]
RewriteRule (.*) /cache/$1.html [L]

Il codice qui sopra dice al server di guardare nella cache solo se la richiesta non contiene una query string (tipo risultati di una ricerca, o per chi vuole vedere i colori degli altri mesi), e se arriva da un utente non autenticato nel pannello di controllo. Poi ovviamente ho aggiunto alcune funzioni, usando gli uncini di WordPress, per fare in modo di cancellare e rigenerare una pagina ogni volta che aggiorno un articolo o che un visitatore lascia un commento. Ed ho anche messo nel cron uno script che, ad inizio mese, mi rigenera l’intera cache (visto che nella barra laterale ho adesso la sezione con l’elenco dell’archivio mensile dei post). Il guadagno in termini di prestazioni non è stato così spettacolare (un paio di punti nel voto finale assegnato da GTMetrix), ma almeno adesso uso meno risorse per la maggior parte delle visite gestite dal server. Così sia io che l’omino talebano possiamo nuovamente dormire sonni tranquilli. E tu, dici che potrei fare di meglio?

P.S.: nel frattempo ho aggiornato il tema per portarmi in casa i due font di Google che uso su queste pagine, così stavolta davvero nessuno tranne me, Supporthost e Gravatar, sa dove vanno gironzolando i miei lettori.

Commenti

  1. Trap
    ha scritto:

    Infatti ho visto che non è così raro imbattersi in progetti che generano siti “statici” a partire da template, come Hugo.

    Concordo che far rigenerare una pagina con gli stessi contenuti a php è uno spreco di risorse. La differenza di tempo è ormai trascurabile con la potenza elaborativa odierna, altro che ai nostri tempi dell’università…

    Risposte al commento di Trap

    1. camu
      ha scritto:

      Si, ho sperimentato con Hugo tempo fa, ed è davvero veloce. La staticizzazione dei siti dovrebbe essere molto più comune di quanto in realtà non lo sia.

  2. ha scritto:

    Il problema sui siti dinamici è dato principalmente dalla zona commenti (e dalle sidebar), tutti i plugin di caching cercano di tenere d’occhio quegli eventi per capire cosa distruggere e rigenerare.
    Bravo comunque per aver rivisto la scelta di una CDN: come vedi tantissime soluzioni vengono spinte dal marketing ancor prima che da reali necessità. Come dicevo in precedenza, una CDN ha senso in contesti particolari.
    Ciao,
    Emanuele

    Risposte al commento di Emanuele

    1. camu
      ha scritto:

      Si, infatti immagino che i plugin di caching devono essere intelligenti nell’adottare politiche che siano generiche abbastanza da andar bene per la stragrande maggioranza dei siti su cui verranno installati. Nel mio caso avevo il lusso di potermi scrivere una soluzione ad-hoc che copre esattamente quello che serve a me, staticizzando e cancellando i contenuti in base ai commenti ecc.

      Per la CDN, non è stato facile districarmi dalle grinfie di Cloudflare. Il ripuntamento dei DNS su SupportHost ha richiesto un intervento da parte del loro servizio clienti per cancellare record DNSSEC ed altre diavolerie esoteriche a cui non avevo diretto accesso dal cPanel. Per fortuna non se n’è accorto nessuno, anche grazie al fatto che l’assistenza SupportHost è attiva anche di notte (prima serata, per me) e quindi abbiamo risolto tutto prima che fosse l’alba in Italia 😉

Rispondi a Trap

Torna in cima alla pagina