Comprendere la memorizzazione nella cache in WordPress, parte 1
A maggio, ho scritto un articolo sull’utilizzo dell’API Transient di WordPress. Riassumo l’articolo in questo modo:
Per simulare i cookie e la loro caratteristica di scadenza, l’utilizzo dei transitori di WordPress può essere una soluzione praticabile.
https://wordpress.mediadoma.com/it/usare-i-transitori-di-wordpress-invece-dei-cookie/
Sebbene lo scopo dell’articolo fosse quello di gettare le basi su come progettare una classe in modo che funzioni con l’API Transients per simulare il comportamento dei cookie, uno degli effetti collaterali dell’articolo è che non ha funzionato bene di spiegare come funziona l’API Transients (e, tramite proxy, come funziona MySQL).
Questo è stato portato alla mia attenzione via e-mail da David di UpDraft Plus.
Quindi ho pensato che fosse utile parlare del concetto di memorizzazione nella cache da un livello pratico, di come viene implementato in WordPress, quindi magari guardare come utilizzare i plug-in o la tecnologia più recente per potenziare meglio i nostri siti e applicazioni e avere una migliore comprensione.
Capire la memorizzazione nella cache: le basi
Il concetto di memorizzazione nella cache è relativamente semplice. Ma penso che sia meglio dimostrato parlando di serializzazione e recupero dei dati senza memorizzazione nella cache, prima.
Senza memorizzazione nella cache
Scrittura di dati
Ogni volta che scrivi informazioni nel database sottostante, stai registrando un record, o una serie di record, nel database.
Ad esempio, quando pubblichi un post, scriverai un record nella tabella per i post e nella tabella per i metadati dei post, ciascuno dei quali è correlato da un ID post.
Il modo in cui sono correlati non è importante per questo post.
Invece, la cosa da capire in questa parte è che quando i dati vengono scritti nel database viene creato almeno un record, se non multiplo.
Lettura dei dati
Quando un visitatore atterra sul sito per leggere quel particolare post, tutte le informazioni per detto post verranno richieste dal database, servite all’applicazione WordPress e quindi visualizzate sul front-end.
Pensa a questo intero processo come a un viaggio:
- ❓il visitatore richiede la pagina,
- 🔍 il web server ha identificato quale pagina caricare,
- 📂 viene richiesta la pagina al database da più tabelle,
- 🏗 i dati vengono assemblati e inviati all’applicazione principale,
- 🖥 i dati vengono presentati all’utente.
Quindi il viaggio inizia quando l’utente richiede una pagina e termina quando le informazioni vengono presentate loro nel browser.
È un viaggio
E, senza memorizzazione nella cache, questo accade per ogni singolo utente. Cioè, per ogni utente che visita il tuo sito, deve essere effettuato un viaggio.
Ciò può diventare molto costoso in termini di risorse e tempo (soprattutto a seconda delle dimensioni del database).
Ma è qui che può entrare in gioco la memorizzazione nella cache.
Prima di entrare nella cache
L’idea alla base della memorizzazione nella cache è di rendere più veloce l’intero processo. Cioè, se sappiamo che sta per accadere un viaggio, possiamo conservare le informazioni in un luogo tale che sia già assemblato e più veloce da recuperare.
Prima di parlarne però, di cui parlerò nel prossimo post, si noti che è come fare un viaggio nell’hard disk del server su cui è ospitato il sito ogni volta che si visita il sito.
Perché, in definitiva, il database, i file e tutte le risorse necessarie per alimentare il sito risiedono su un disco rigido. E sì, cose come le unità a stato solido possono rendere questo processo più veloce, ma non è ancora il più ottimale possibile.
Ed è qui che entra in gioco la memorizzazione nella cache. Per comprendere meglio l’API Transient, è importante comprendere la memorizzazione nella cache, che richiede innanzitutto una comprensione di base di come funzionano le cose senza la memorizzazione nella cache.
È un primer
Quindi considera questo un primer di base su come funziona un sito supportato da database senza memorizzazione nella cache. E poi ci svilupperemo di più su questo nel prossimo post.