La cache è una componente essenziale di Wedgefish.
Grazie ad essa la piattaforma riesce ad offrire alte prestazioni e tempi di risposta rapidi nonostante la sua notevole complessità strutturale.
È quindi fondamentale per garantire scalabilità in caso di un elevato flusso di richieste.
La cache utilizzata da Wedgefish è implementata come una classe contenuta in un modulo, caricato ed istanziato dinamicamente durante la fase di bootstrap.
Di default, la piattaforma utilizza una cache basata su files ed un indice memorizzato su database; è possibile sostituire tale modulo con un'altra implementazione, come ad esempio una cache che fa uso interamente di database, utile in ambienti cluster o di hosting condiviso (qualora sia attivo il safe-mode o semplicemente sia preferibile un approccio di questo tipo per motivi prestazionali o di sicurezza).
Ogni modulo può decidere di creare un nuovo tipo di cache, secondo le sue esigenze.
Sono presenti di base varie cache, ciascuna destinata a contenere informazioni di tipo differente:
- la cache del codice compilato
- la cache degli scripts generati
- la cache del contenuto generato
- la cache del codice SQL
- la cache della configurazione
- la cache delle immagini rielaborate
Ad esse può essere aggiunta la cache delle immagini rielaborate, utilizzata dal modulo imageprocessor.
È possibile definire un diverso metodo di memorizzazione per ciascun tipo, ad esempio files per la cache del codice e database per la cache del contenuto (*) oppure semplicemente, nel caso della cache basata su files, una diversa cartella per la memorizzazione. Questo consente di venire incontro alle esigenze di taluni sistemi clustered, ove le modifiche ai files non vengono sovente replicate in tempo reale.
La cache del codice compilato
Tutto il codice eseguito in Wedgefish (tranne alcuni script raccolti nella cartella "system/bootstrap") vengono trattati preliminarmente tramite il preprocessore di codice, che provvede ad ottimizzarli e ad effettuare particolari sostituzioni secondo le esigenze (come il valore delle costanti).
Gli script PHP risultanti vengono quindi memorizzati per essere semplicemente inclusi ai successivi utilizzi, se l'originale non è stato modificato nel frattempo.
Abbinata a tale cache vi è un'altra sottocache, debuginfo, che contiene la corrispondenza tra i nomi di file ed i numeri di riga dei sorgenti originali e quello dei sorgenti processati ed altri dati. Essa viene utilizzata dal gestore di errore per restituire messaggi maggiormente informativi rispetto a quanto verrebbe visualizzato da PHP.
La cache degli scripts generati
Come illustrato nella pagina che spiega il sistema di templating di Wedgefish, ogni URL definito nel WODBMS è associato ad una view e ad un controller.
Questi due files vengono assemblati e compilati automaticamente in uno script, che viene quindi eseguito come se si trattasse di una normale pagina dinamica creata dal programmatore.
Per evitare di dover ripetere ad ogni richiesta il processo di compilazione, lo script generato viene memorizzato nella cache degli scripts, dalla quale verrà incluso ed eseguito successivamente, risparmiando molto tempo.
La cache del contenuto
Questa cache associa l'output generato per un determinato URL a tutti gli oggetti e le classi che hanno contribuito a crearlo.
Qualora anche solo uno di essi venga modificato, il contenuto verrà considerato scaduto e quindi nuovamente generato dinamicamente.
Essa è strettamente dipendente dall'utilizzo del WODBMS: qualora il contenuto di un URL sia stato generato a partire da database convenzionali, non potrà essere utilizzata e dovrà essere disabilitata per tale indirizzo.
La cache del codice SQL
L'implementazione del WODBMS basata su SQL "traduce" le interrogazioni espresse tramite l'utilizzo di funzioni quali wos_query_items e wos_get_items in una serie di query SQL, che eseguite una di seguito all'altra provvedono a restituire i dati richiesti, che vengono poi inseriti in un array o in un oggetto e restituiti al chiamante.
La generazione di questo codice SQL richiede risorse da parte del server, ed è stato quindi previsto un meccanismo di memorizzazione delle stesse, che consente di evitare di ripetere nuovamente tale processo quando vengono eseguite nuove interrogazioni con gli stessi parametri.
Non è necessario cancellare tali query quando i dati nel WODBMS vengono modificati, poiché esse restituiscono comunque i dati aggiornati una volta eseguite. Esse costituiscono semplicemente l'equivalente in SQL di quanto espresso secondo la sintassi di accesso ai dati del WODBMS.
La cache della configurazione
Questa cache è destinata a contenere la versione serializzata del file di configurazione globale, allo scopo di consentirne un più veloce caricamento.
La cache delle immagini rielaborate
Questa particolare cache, utilizzata da moduli di trattamento dinamico delle immagini quali ad esempio imageprocessor, memorizza le versioni rielaborate delle immagini originali (scalate, ruotate ecc...) associandole al checksum md5 del file originale e ad una serie di variabili, in maniera che non sia necessario ripetere nuovamente l'esecuzione delle routine della libreria gd quando l'immagine viene nuovamente trattata con gli stessi identici parametri (larghezza, altezza, qualità ecc...).
La sua presenza consente ad esempio di far riferimento alla stessa immagine (con gli stessi parametri) da più URL, senza per questo dover eseguire il trattamento per ciascuno di essi, ed anche di cancellare la cache dell'output senza per questo dover rielaborare nuovamente tutte le immagini (quando richieste, le versioni rielaborate delle immagini verranno lette da tale cache e copiate nella cache dell'output).
Tale accorgimento consente di risparmiare molto tempo in presenza di originali di dimensioni notevoli.
È anche possibile copiare il contenuto di tale cache da un server ad un altro in caso di spostamento del sistema, consentendo di risparmiare il tempo necessario per rielaborare tutte le immagini dagli originali (sebbene sia necessario comunque prendere in considerazione il tempo necessario per il trasferimento dei dati).