Un pannello di filtri che impiega quattro secondi a rispondere è percepito come rotto. Il problema è raramente il modulo in sé: viene dal modo in cui le query sono costruite e da ciò che il database deve percorrere per rispondervi.
Ecco come localizzare la causa prima di cambiare qualsiasi cosa.
Misurare prima di supporre
Tre rilevazioni, in quest’ordine.
Il tempo di risposta reale di una richiesta di filtraggio, misurato nella scheda rete del browser sulla vostra categoria più grande con due o tre filtri attivi. Annotate il valore: è il vostro punto di partenza.
La parte di questo tempo passata nel database. Attivate il profiling di PrestaShop in ambiente di test: mostra il numero di query eseguite e la loro durata cumulata. Se il tempo database rappresenta l’80 % del totale, inutile guardare altrove.
Il numero di query eseguite. È spesso la rivelazione: una pagina di categoria filtrata che esegue trecento query ha un problema di progettazione, non di potenza del server.
Questo terzo punto merita attenzione. Una moltiplicazione delle query segnala generalmente un calcolo di contatori valore per valore, o un caricamento dei prodotti uno a uno in un ciclo.
Le quattro cause principali
Le join sulle tabelle degli attributi. Filtrare su tre attributi presuppone di unire più volte le tabelle dei valori. Su un catalogo di ventimila combinazioni, queste join producono insiemi intermedi considerevoli.
Il calcolo dei contatori. Mostrare il numero di risultati dietro ogni valore presuppone un’aggregazione per valore. Su un pannello di sessanta valori, ciò può fare sessanta aggregazioni a ogni cambio di selezione.
Il conteggio totale per la paginazione. Contare le righe di una selezione ampia costa quasi quanto leggerle.
Gli indici mancanti. Sulle tabelle di collegamento tra prodotti, attributi e categorie, un indice assente trasforma una ricerca in scansione completa della tabella.
Diagnosticare gli indici
È la verifica più redditizia e più rapida.
Recuperate la query di filtraggio più lenta dal log delle query lente del vostro database, poi eseguitela preceduta dalla parola chiave di spiegazione del piano di esecuzione.
Tre segnali da individuare nel risultato.
Un tipo di accesso che indica una scansione completa su una tabella voluminosa. È il segno di un indice assente o inutilizzabile.
Un numero di righe esaminate senza alcuna proporzione con il numero di righe restituite. Esaminare duecentomila righe per restituirne quaranta indica che il filtraggio avviene dopo la lettura piuttosto che per indice.
La menzione di un ordinamento temporaneo o di una tabella temporanea, che segnala che il database non può soddisfare l’ordinamento per indice e deve materializzare un risultato intermedio.
Punto pratico: gli indici utili su queste tabelle riguardano spesso colonne combinate, e il loro ordine conta. Un indice su prodotto poi attributo non serve le stesse query di un indice su attributo poi prodotto.
Filtri a Faccette AJAX per PrestaShopLa navigazione a faccette che filtra veloce e indicizza bene€99.00
Ridurre il lavoro piuttosto che accelerarlo
Prima dell’ottimizzazione tecnica, tre decisioni funzionali hanno spesso più effetto.
Ridurre il numero di filtri. Ogni attributo filtrabile aggiunge join potenziali e contatori da calcolare. Dodici filtri di cui quattro usati costano tre volte troppo.
Rinunciare ai contatori sui grandi cataloghi, o calcolarli solo sui filtri più usati. Il comfort perso è reale, il guadagno di tempo anche.
Limitare la profondità di combinazione. Oltre tre filtri simultanei, le selezioni diventano rare e costose. Potete mettere un tetto senza che nessuno se ne accorga.
Queste tre misure non richiedono alcuno sviluppo e si testano in un pomeriggio.
L’indice dedicato
Quando le misure precedenti non bastano, la risposta strutturale consiste nel non interrogare più le tabelle di catalogo al momento del filtraggio.
Il principio: una tabella piatta, precalcolata, contenente per ogni prodotto i suoi valori filtrabili, il suo prezzo, la sua disponibilità e le sue categorie. Il filtraggio diventa una query semplice su una sola tabella indicizzata.
Tre punti di attuazione.
L’aggiornamento deve scattare a ogni modifica di prodotto, di prezzo o di stock. Un indice desincronizzato mostra prodotti che non esistono più o nasconde novità.
La ricostruzione completa deve restare possibile, e il suo tempo di esecuzione misurato: su un grande catalogo, può richiedere diversi minuti e non deve eseguirsi nelle ore di punta.
Lo scatto in massa. Un import di catalogo che modifica diecimila prodotti non deve scatenare diecimila ricostruzioni unitarie. Prevedete una modalità differita.
La cache, e i suoi limiti
La cache è utile ed è spesso mal impiegata su questo tema.
Mettere in cache i risultati di filtraggio funziona bene quando le combinazioni richieste sono poche e ripetute. È il caso sulla maggior parte dei negozi: qualche decina di combinazioni copre l’essenziale del traffico.
Due limiti da conoscere. La cache non tratta la prima visita di ogni combinazione, che resta lenta. E deve essere invalidata a ogni cambio di stock o di prezzo, altrimenti mostrate informazioni false.
Sui dati di disponibilità, la durata di cache deve restare breve, qualche minuto, il che riduce fortemente il suo interesse. Un approccio corrente consiste nel mettere in cache la lista dei prodotti corrispondenti e recuperare prezzo e stock in diretta.
Le verifiche lato infrastruttura
Tre punti che non riguardano il codice.
La memoria assegnata al database. Un database che non può tenere i suoi indici in memoria li rilegge dal disco a ogni query. È la causa più frequente di lentezza generalizzata dopo una crescita di catalogo.
La configurazione della cache delle query e dei buffer, da regolare secondo la taglia reale dei vostri dati piuttosto che restare sui valori predefiniti dell’installazione.
Le risorse concorrenti. Un export di catalogo o un’attività pianificata che si esegue contemporaneamente al picco di traffico degrada tutto. Spostate ciò che può esserlo.
Il percorso completo
Sei tappe, in quest’ordine di redditività decrescente.
1. Misurate il tempo di risposta e il numero di query.
2. Verificate gli indici con un piano di esecuzione sulla query più lenta.
3. Riducete il numero di filtri proposti ai soli usati.
4. Disattivate o limitate i contatori se il catalogo è importante.
5. Mettete in atto una cache sulle combinazioni frequenti.
6. Considerate un indice dedicato se le prime cinque tappe non bastano.
Punto di metodo: misurate dopo ogni tappa. Superare più tappe in una volta vi priva di sapere quale ha prodotto l’effetto, e quindi di sapere dove concentrare lo sforzo la prossima volta.
Il modulo Filtri a Faccette AJAX per PrestaShop integra questi meccanismi su PrestaShop 8 e 9: indice dedicato precalcolato con aggiornamento incrementale, contatori di risultati in aggregazione unica, cache per combinazione con invalidazione sui cambi di stock e di prezzo, e limitazione parametrizzabile della profondità di combinazione.
