La web Cache non risolve i problemi, ma nasconde la polvere sotto al tappeto

C’è una richiesta che riceviamo quasi ogni settimana, con parole sempre diverse e sempre la stessa sostanza: “il sito è lento, ci serve un hosting più veloce” oppure “attivateci la cache, così si risolve”. Dietro, quasi sempre, c’è un sito bellissimo da vedere, curato nella grafica, con un tempo di risposta del server che supera i tre o quattro secondi prima ancora che il browser inizi a disegnare la pagina.

Il cliente ha ragione a chiedere un sito veloce. Ha torto, o meglio è stato portato a credere una cosa sbagliata, quando pensa che la velocità si compri cambiando hosting o accendendo una cache. La web cache non risolve i problemi: li nasconde, come la polvere sotto al tappeto. Funziona finché nessuno solleva il tappeto. Poi qualcuno lo solleva: un cliente che mette un prodotto nel carrello, un utente che fa login, un bot che chiede una pagina mai vista, una campagna pubblicitaria che porta traffico su pagine non in cache. E la polvere è ancora tutta lì.

In questo articolo voglio spiegare perché succede, perché la responsabilità viene scaricata così spesso sull’hosting e cosa significa davvero ottimizzare un’applicazione, dal database a PHP, passando per la profilazione e la ricerca dei colli di bottiglia.

Siti belli, performance vergognose

Negli ultimi anni costruire un sito è diventato facilissimo. Un tema acquistato, un page builder, una ventina di plugin per aggiungere funzioni, e in pochi giorni il sito è online. È un progresso enorme, e non lo dico con nostalgia. Ma questa facilità ha un prezzo che raramente viene spiegato: ogni plugin, ogni modulo, ogni funzione aggiunta con un clic esegue codice e interroga il database a ogni pagina, e quasi nessuno sa quanto costi.

Il risultato lo vediamo tutti i giorni. Pagine che eseguono centinaia di query al database per mostrare un elenco di prodotti. Plugin che caricano a ogni richiesta opzioni che non servono. Ricerche che scorrono tabelle intere da milioni di righe perché manca un indice. Chiamate a servizi esterni fatte durante la generazione della pagina, che aspettano risposte da server lontani. Ogni singola scelta sembra innocua; sommate, portano a TTFB di quattro secondi e oltre.

Il problema delle basi

Lo dico con franchezza, perché lavoro in questo settore da molti anni e credo che sia necessario dirlo: troppo spesso chi si presenta come sviluppatore non lo è. È qualcuno che sa installare e configurare plugin, che conosce bene un page builder, che sa rendere un sito gradevole. Sono competenze utili, ma non sono sviluppo software.

Molte di queste figure non hanno alle spalle un percorso accademico in informatica, e spesso nemmeno una formazione tecnica come quella del vecchio ITIS a indirizzo informatico, dove si studiavano algoritmi, strutture dati, basi di dati e sistemi. Non è una questione di titoli da appendere al muro: conosco ottimi professionisti autodidatti, che hanno studiato da soli e sul serio. È una questione di basi teoriche. E quando le basi mancano, si vede nel momento esatto in cui qualcosa va storto.

Mancano concetti che dovrebbero essere il pane quotidiano di chi scrive o assembla software:

• il costo di ogni operazione: leggere una riga tramite un indice è diverso dallo scorrere una tabella intera, e la differenza cresce con i dati. Una funzione che va bene con cento prodotti diventa un disastro con centomila;
• le buone pratiche di una base di dati: normalizzazione dove serve, tipi di dato corretti, chiavi e vincoli, tabelle che non crescono senza controllo;
• il concetto di query lenta: sapere che esiste, come si individua, perché una query che impiega due secondi eseguita a ogni pagina mette in ginocchio qualsiasi server;
• l’utilità degli indici: cosa sono, quando servono, quando fanno danno, come il database decide se usarli;
• la differenza tra lavoro fatto una volta e lavoro fatto a ogni richiesta: calcoli che potrebbero essere salvati e invece vengono ripetuti migliaia di volte al giorno.

Senza queste basi, quando il sito rallenta non si sa da dove cominciare. Si prova un plugin di ottimizzazione, poi un altro, poi si comprimono le immagini, poi si minifica il CSS. Tutte cose che migliorano il caricamento lato browser, ma che non toccano il problema vero: il server che impiega quattro secondi a generare la pagina.

La scorciatoia: “cambiamo hosting e attiviamo la cache”

A questo punto il cliente, comprensibilmente stanco, cerca la soluzione più semplice. Se il sito è lento, sarà colpa del server. Si cambia hosting, si sceglie un piano più costoso, si chiede di attivare la cache. Ed effettivamente, per un po’, qualcosa migliora: le pagine visitate più spesso dai visitatori anonimi vengono servite dalla cache in pochi millisecondi.

Ma una web cache conserva copie di pagine già generate. Non rende più veloce la generazione delle pagine; evita solo di ripeterla, quando può. E ci sono tante situazioni in cui non può:

• gli utenti autenticati, che vedono pagine personali e non possono ricevere la copia di qualcun altro;
• il carrello e il checkout di un e-commerce, cioè proprio le pagine in cui si guadagna;
• l’area amministrativa, dove chi gestisce il sito lavora ogni giorno e aspetta secondi per ogni salvataggio;
• le ricerche e i filtri, che generano combinazioni quasi infinite e raramente si ripetono;
• la prima visita di ogni pagina dopo una scadenza o un aggiornamento, che deve comunque essere generata;
• i bot e i crawler, che chiedono sistematicamente pagine che nessun altro chiede.

In tutti questi casi la richiesta arriva all’applicazione e paga per intero i suoi quattro secondi. Il sito sembra veloce quando lo si prova dalla home da anonimi; è lento esattamente dove conta.

Ne abbiamo già parlato a proposito dei cataloghi e della navigazione faccettata e della favola della cache che risolve tutto: la cache è uno strumento eccellente, che usiamo ovunque, ma è uno strato che si appoggia sopra un’applicazione sana. Non sostituisce un’applicazione sana.

Anche dall’altra parte della barricata mancano le competenze

Il cliente, a quel punto, si rivolge all’hosting sperando di trovare chi risolva. E qui spesso trova un’altra delusione. Molti fornitori di hosting hanno un supporto tecnico preparato sulla propria infrastruttura, ma le figure che rispondono, per formazione e per ruolo, non sono sviluppatori e tanto meno DBA. Sanno riavviare un servizio, aumentare la memoria, attivare un modulo di cache. Non si addentrano nell’applicazione, perché non è il loro mestiere e spesso non è previsto dal servizio.

Così la risposta tipica diventa una delle tre classiche: “il problema è applicativo, si rivolga al suo sviluppatore”, oppure “passi al piano superiore”, oppure “attivi il nostro sistema di cache”. Nessuna delle tre è sbagliata in senso stretto, ma nessuna risolve. Il cliente torna dallo sviluppatore, che non sa da dove partire, e il cerchio si chiude.

Per uscire da questo cerchio servono competenze che stanno a metà strada tra sistemi e sviluppo, e che pochi hanno insieme:

• la profilazione dell’applicazione con strumenti APM come Datadog o New Relic, che mostrano dove va il tempo di ogni richiesta: quale funzione, quale plugin, quale query, quale chiamata esterna;
• più semplicemente, la profilazione con gli strumenti già presenti sul server: il log delle richieste PHP lente, che indica in quale punto del codice un processo è rimasto bloccato, e il log delle query lente del database, che raccoglie le interrogazioni che superano una soglia di tempo;
• la lettura del piano di esecuzione di una query, cioè il risultato del comando EXPLAIN, che dice come il database intende recuperare i dati: se usa un indice, quante righe pensa di leggere, se deve creare tabelle temporanee o ordinare su disco;
• la capacità di intervenire: creare l’indice giusto, riscrivere una query, spostare un calcolo fuori dal percorso critico, sostituire un plugin che fa cento query con una soluzione che ne fa una.

Leggere un EXPLAIN e riscrivere una query non è magia, ma richiede proprio quelle basi di cui parlavo prima. E richiede di accettare che il problema stia nell’applicazione, non nell’hardware.

Un esempio: quando manca un indice

Per capire di cosa stiamo parlando basta un caso molto comune. Un e-commerce con due milioni di ordini storici mostra, in una pagina dell’area clienti, gli ultimi ordini dell’utente. La query cerca gli ordini per cliente e li ordina per data. Senza un indice adatto, il database non ha alternative: scorre tutta la tabella, due milioni di righe, poi ordina il risultato. Su un server moderno ci vuole qualche secondo; con dieci utenti contemporanei il database è saturo.

Con un indice composto su cliente e data, la stessa query legge solo le poche righe di quel cliente, già nell’ordine giusto. Il tempo scende a pochi millisecondi. Nessun cambio di hosting, nessuna cache: un’operazione di pochi secondi da parte di chi sa cosa sta facendo. Questo è l’esempio più semplice, quello da manuale; nella realtà i casi sono spesso più intricati, con query generate da plugin, join su tabelle di metadati enormi, opzioni caricate a ogni richiesta, ma il principio non cambia.

Perché il problema peggiora con il tempo

C’è un aspetto che rende la polvere sotto al tappeto ancora più insidiosa: cresce da sola. Un sito appena pubblicato ha poche pagine, pochi prodotti, pochi ordini, tabelle piccole. Anche una query scritta male, su una tabella piccola, risponde in fretta. Poi passano i mesi. Gli ordini diventano decine di migliaia, i log dei plugin si accumulano, le revisioni dei contenuti si moltiplicano, le tabelle dei metadati arrivano a milioni di righe. La stessa query, senza che nessuno abbia toccato una riga di codice, impiega dieci o cento volte di più.

Nel frattempo si aggiungono altri plugin, ciascuno con le sue interrogazioni a ogni pagina, e il traffico aumenta, magari proprio grazie al successo del sito. Il risultato è un degrado lento e costante, che nessuno nota finché non supera una soglia: il giorno del Black Friday, durante una campagna, dopo un’uscita sui social. A quel punto la cache non basta più, perché il traffico si sposta sulle pagine che non può coprire, e il server crolla nel momento in cui servirebbe di più.

Per questo l’ottimizzazione applicativa non è un intervento da fare una volta sola, ma un’abitudine: misurare periodicamente, tenere sotto controllo la crescita delle tabelle, rivedere le query più costose quando i dati cambiano di ordine di grandezza.

Cosa facciamo in Managed Server

In Managed Server abbiamo scelto di non fermarci al server. Ottimizziamo naturalmente lo stack: web server, PHP-FPM, cache applicative come Redis, reverse proxy come Varnish, database, file system, rete. Ma quando il collo di bottiglia è nell’applicazione, entriamo nell’applicazione.

Il nostro lavoro segue un metodo preciso:

1. misura: prima di toccare qualsiasi cosa, raccogliamo dati reali. Tempi di risposta per tipo di pagina, distinguendo le pagine servite dalla cache da quelle generate, carico del database, processi PHP impegnati;
2. profilazione: con strumenti APM dove disponibili, e sempre con il log delle richieste PHP lente e quello delle query lente di MySQL, MariaDB o PostgreSQL, individuiamo dove va davvero il tempo;
3. individuazione dei colli di bottiglia: la query senza indice, il plugin che fa decine di interrogazioni, la tabella cresciuta senza controllo, la chiamata esterna sincrona, la configurazione di PHP inadatta al carico;
4. risoluzione: indici, riscrittura delle query, pulizia del database, configurazione di PHP e del database su misura, cache applicativa dove ha senso, sostituzione o correzione dei componenti responsabili;
5. verifica: rimisuriamo con gli stessi criteri dell’inizio, perché un’ottimizzazione senza numeri è solo un’opinione.

Solo dopo, sopra un’applicazione che risponde in tempi ragionevoli anche senza cache, la web cache diventa ciò che deve essere: un acceleratore che porta le pagine pubbliche a pochi millisecondi e protegge il server nei picchi, non un tappeto sotto cui nascondere quattro secondi di inefficienza.

È lo stesso approccio che abbiamo applicato al nostro sito, come abbiamo raccontato nella cronaca di una vera ottimizzazione: si parte dai numeri, si cerca la causa, si interviene sulla causa.

Un consiglio a chi commissiona un sito

Se state per commissionare un sito o un e-commerce, chiedete a chi lo realizza come verificherà le prestazioni lato server, non solo il punteggio di PageSpeed. Chiedete quanto impiega a generarsi una pagina senza cache, quante query esegue la pagina più visitata, cosa succede con diecimila prodotti invece di cento. Le risposte vi diranno molto più di un portfolio.

E se il sito è già online e lento, diffidate di chi vi propone come unica soluzione un piano più costoso o una cache più “intelligente”. A volte serve davvero più potenza; molto più spesso serve qualcuno che sollevi il tappeto e guardi cosa c’è sotto.

Conclusioni

La web cache è uno degli strumenti più efficaci che abbiamo, e la usiamo su tutti i progetti che gestiamo. Ma è un acceleratore, non una cura. Un sito che impiega quattro secondi a generare una pagina resta un sito che impiega quattro secondi, solo che il problema si manifesta nei momenti peggiori: al checkout, durante i picchi, nell’area clienti, sotto l’assalto dei bot.

Le prestazioni vere nascono dalle basi: capire il costo delle operazioni, progettare bene il database, usare gli indici, misurare prima di intervenire. Quando queste basi mancano nello sviluppo, servono competenze capaci di recuperarle a valle. Se il tuo sito è lento e nessuno finora ha saputo dirti perché, parliamone: con la nostra consulenza su MySQL e MariaDB, l’ottimizzazione delle prestazioni e i nostri server gestiti lavoriamo su tutto lo stack, dal database all’applicazione, fino alla cache.