Perché la ricerca di PrestaShop rallenta quando il catalogo cresce

Il sintomo

Con un catalogo demo di 20 o 30 prodotti, la ricerca di PrestaShop funziona sempre bene: qualunque configurazione si scelga, la pagina risponde in una frazione di secondo. Il problema si vede solo quando il catalogo cresce davvero, e a quel punto è tardi per accorgersene: un negozio con 50.000, 100.000 o 200.000 prodotti può avere una pagina di ricerca che impiega diversi secondi a rispondere, o una pagina di categoria con i filtri che diventa la più lenta di tutto il sito.

Non è una sensazione. Su un catalogo sintetico da 200.000 prodotti, con il motore di ricerca nativo di PrestaShop (quello che gira dentro il database del negozio, senza un motore esterno), una pagina di risultati di ricerca impiegava 28 secondi e una pagina di categoria grande 30 secondi prima di un lavoro mirato di ottimizzazione. Dopo, la stessa pagina va tra i 2 e i 6 secondi. Restano secondi, non millisecondi: è il punto di questo articolo, capire perché.

Perché il tempo cresce più in fretta del catalogo

La causa più comune non è "il database è lento", è che lo stesso lavoro viene rifatto più volte nella stessa richiesta. Un motore di ricerca a faccette deve rispondere a due domande diverse per ogni pagina: quali prodotti mostrare, e per ogni filtro disponibile, quanti prodotti risulterebbero se il visitatore lo selezionasse. Se il calcolo dell'insieme di prodotti che soddisfa la ricerca corrente viene rifatto da zero per ogni filtro, invece di essere calcolato una volta e riusato, il costo smette di essere proporzionale al numero di prodotti e diventa proporzionale al numero di prodotti moltiplicato per il numero di filtri. Su un catalogo piccolo la differenza non si nota. Su 200.000 prodotti con decine di filtri attivi, una ricerca che in teoria tocca cinque prodotti può finire per scandire l'intero catalogo una decina di volte.

Lo stesso vale per pezzi più piccoli ma ripetuti tantissime volte: se il prezzo di ogni prodotto in una pagina di categoria viene chiesto al database uno alla volta invece che in blocco, cento prodotti a pagina diventano facilmente centomila query interrogando il prezzo prodotto per prodotto su un catalogo grande con regole di prezzo per gruppo o per quantità. Nessuna di queste query, presa da sola, è lenta. È il numero di query a diventare insostenibile.

Il costo nascosto dei numeri accanto ai filtri

C'è un secondo costo, distinto dal primo, ed è mostrare quanti prodotti corrispondono a ciascun valore di un filtro (il classico "Rosso (12)" accanto a una casella). Con un motore di ricerca esterno (Elasticsearch, OpenSearch, Meilisearch) quel numero arriva gratis, come parte della stessa interrogazione che calcola i risultati. Con il motore nativo, che lavora dentro il database del negozio, ogni singolo valore di ogni filtro può richiedere una interrogazione propria di conteggio.

Su un catalogo da 200.000 prodotti con circa 2.250 gruppi di attributi e caratteristiche, disattivare il conteggio esatto sui filtri (mostrare l'elenco dei valori senza il numero a fianco) ha portato una pagina di categoria con un filtro attivo da 43,3 secondi a 11,9 secondi. Sulle sole faccette di caratteristiche e attributi, il tempo è sceso da 6,8 e 5,4 secondi rispettivamente a 15 e 19 millisecondi. Non è un arrotondamento: è la differenza tra un'interrogazione che deve contare righe una per una nel database e una che si limita a leggere un elenco di valori distinti fino a un certo numero, senza contarli tutti.

Per chi gestisce il negozio la domanda pratica è semplice: quel numero tra parentesi vale il suo costo? Su un catalogo di poche migliaia di prodotti quasi certamente sì. Su un catalogo di centinaia di migliaia di prodotti con molte caratteristiche, può essere la voce di costo più pesante di tutta la pagina, ed è spesso una casella di configurazione, non una riscrittura del codice.

Cosa dice un test reale su un catalogo di quella taglia

Su un catalogo sintetico di 200.321 prodotti, un test interno sulla pagina di ricerca completa (calcolo dei risultati più tutte le faccette) ha misurato tempi di risposta tra 2,2 e 2,4 secondi. È un numero coerente con l'intervallo di 2-6 secondi citato sopra, ottenuto su un allestimento diverso: due misure indipendenti che raccontano la stessa cosa, un catalogo di quella dimensione risponde in un tempo che si misura in secondi, non in decimi di secondo, anche dopo un buon lavoro di ottimizzazione. Chi promette il contrario su un catalogo di quella taglia con il solo motore nativo del database sta probabilmente misurando su un catalogo più piccolo di quanto dichiara.

Cosa controllare prima di scoprirlo in produzione

• Fate almeno un test con un volume di prodotti vicino a quello reale, non con il catalogo demo. I problemi di questo tipo sono invisibili sotto le diecimila righe e molto visibili sopra.
• Controllate il limite di memoria PHP del vostro hosting. Molti piani condivisi restano a 128 o 256 MB: operazioni che caricano righe di database in memoria invece di lasciarle contare al database possono superarlo su cataloghi grandi con molte caratteristiche o attributi importati da CSV.
• Se usate il motore nativo su un catalogo grande, verificate se potete disattivare i conteggi esatti sui filtri, o se conviene passare a un motore esterno (Elasticsearch, OpenSearch o Meilisearch) che li calcola come sottoprodotto della stessa interrogazione.
• Chiedete, di qualunque modulo di ricerca stiate valutando, se il costo è stato misurato su un catalogo grande davvero, con un numero. "Veloce" senza un numero accanto non dice molto.

In sintesi

La ricerca di PrestaShop non rallenta per un difetto misterioso: rallenta perché del lavoro viene ripetuto più volte del necessario, ed emerge solo quando il catalogo cresce abbastanza da renderlo visibile. Le due leve più semplici da controllare sono se lo stesso insieme di risultati viene riusato tra un filtro e l'altro, e se i numeri accanto ai filtri vengono calcolati in modo economico o costoso. Su questo genere di problemi abbiamo passato mesi a misurare e correggere dentro cll_essearch, il nostro modulo di ricerca e navigazione a faccette per PrestaShop, che lavora sia con il motore nativo sia con Elasticsearch, OpenSearch e Meilisearch: se riconoscete i sintomi di questo articolo nel vostro negozio, è il tipo di problema che il modulo è nato per risolvere.

Ricerca Elasticsearch & Navigazione a FaccetteRicerca velocissima e tollerante ai refusi con navigazione a faccette con pannello filtri modale, con motore…99,99 €Vedi il prodotto