administrator  Ott.04.2013 0 Comments

Chi utilizza il modulo view (perché c'è qualcuno che non lo utilizza?) di Drupal conosce bene uno dei pochi limiti su cui prima o poi tutti ci andiamo a scontrare: le query sempre più complesse e dispendiose in termini di prestazioni lato server che vengono costruite. Più filtri sui campi si vanno ad inserire, più campi si vanno ad aggiungere e più la query che il modulo view deve gestire diventa complessa e pesante. Ma come sempre in Drupal c'è una soluzione, anzi due: modificare tramite un modulo custom la query che viene eseguita così da togliere le ridondanze, ma dobbiamo avere delle conoscenze di PHP e di SQL, oppure andare ad utilizzare la cache interna al modulo che pero' si porta con se un piccolo problema: i fitri esposti proprio non li supporta. O forse possiamo dire “non li supportava” ? E senza dover sapere nulla di PHP. Basta una piccola “pezza”.

Iniziamo dalla base e proviamo a creare una vista qualsiasi inserendo un filtro esposto. Per questo esempio io ho creato una vista con un filtro sulla categoria (term reference) associata ad ogni articolo di prova.

Prima di continuare, e solo per testare quello che stiamo andando a fare, installiamo anche il modulo devel e nella pagina della configurazione (admin/config/development/devel) abilitate le opzioni:

  • Display page timer

  • Display memory usage

E se proprio vogliamo vedere le query che fa il sistema abilitiamo anche Display query log. Non è importante se la visualizzazione avverrà in ordine cronologico oppure in ordine di tempo usato per l'esecuzione della query. Da ora in poi a fine pagina troverete il tempo necessario a generare la pagina (quindi tutta la lavorazione) e l'elenco delle query con relativi tempi di risposta. Ricordatevi di disabilitare queste impostazioni quando non vi serviranno più.

Ora che abbiamo la nostra vista proviamo la prima esecuzione. Proviamone un'altra, questa volta con l'uso di una categoria come filtro attivo. Tutto funziona regolarmente. Ora abilitiamo la cache delle viste (l'opzione si trova nella sezione Advanced dei settaggi della vista) scegliendo di appoggiarci ad una cache “Time based” e settando entrambi i campi a 1 ora (il default).

Salviamo e proviamo a rieseguire la cache:

  • provate ad eseguire una ricerca senza utilizzare nessun filtro: la query viene eseguita regolarmente.

  • Provate ad eseguire una ricerca utilizzando un filtro: la query viene eseguita regolarmente (avete un output differente da prima)

  • provate ad eseguire una ricerca con un filtro differente: la query viene eseguita... regolarmente se si fosse scelto il filtro di prima, ma noi abbiamo scelto un altro filtro, eppure la pagina ci presenta il form del filtro con settato il filtro della precedente esecuzione.

Qualsiasi filtro si tenti di utilizzare la pagina risultante sarà quella della prima esecuzione con i filtri, form compreso.

Colpa della cache: nel modulo views i filtri esposti fanno parte della query eseguita, che è stata cache-ata e con essa anche i filtri esposti utilizzati hanno subito la stessa cosa, portandosi con loro il settaggio utilizzato al momento di creare la copia di cache.

Ma come si diceva ad inizio post c'è la soluzione: una piccola pezza (o patch) da installare sul modulo views. In ZiobuddaLabs l'abbiamo scoperta all'interno di questo thread https://drupal.org/node/1055616 (andate al commento 88 per trovare la patch) proprio per cercare di risolvere il problema di performance del modulo view su un VPS di un cliente. E se anche i VPS dei nostri clienti sono ibridi (dischi SSD e SATA) un aiuto da parte della cache permette di gestire più pagine viste senza dover andare ad utilizzare VPS di taglio maggiore.

 

Per applicare la patch è necessario, dopo averla ovviamente scaricata, copiarla all'interno della cartella principale del modulo views (di solito è /sites/all/modules/views) ed eseguire il comando:

patch -p1 < views_1055616_81_cache.patch

 

A video dovreste vedere queste tre scritte:

patching file plugins/views_plugin_cache.inc
patching file plugins/views_plugin_query_default.inc
patching file tests/views_cache.test

Attenzione: questa patch ha problemi quando si utilizza il PHP per visualizzare delle informazioni all'interno della area HEADER o FOOTER. Ma di solito queste cose (l'uso del PHP all'interno di textarea) non si fanno se non in casi limite, vero???!!!

 

Riproviamo la nostra pagina di test. Prima senza filtri. Ok. Ora con un filtro qualsiasi. Ok. Ora con un altro filtro. Ok, la pagina è diversa. La cache funziona. Per provare a verificare che la cache funzionasse realmente in ZiobuddaLabs abbiamo modificato il plugin views_plugin_cache.inc e abbiamo fatto stampare a video la chiave della cache utilizzata e abbiamo ricevuto questi 3 valori:

  • nessun filtro: prova_per_cache:page:results:f1b3c0bc217b04f8ba23df84500c5782

  • filtro 1: prova_per_cache:page:results:52568fb0444347aca7792bcd205b89e6

  • filtro 2: prova_per_cache:page:results:663fc5f48570bdd64ee836dddc5ece5a

 

Grazie a questa patch il VPS del cliente riesce ad eseguire molte più pagine viste e noi non abbiamo dovuto effettuare nessuna modifica alle query tramite il PHP e MySQL.