Perché il checkout di PrestaShop rallenta quando si aggiunge un motore di ricerca esterno

Un effetto collaterale che non ti aspetti

Chi installa Elasticsearch, OpenSearch o Meilisearch su PrestaShop lo fa quasi sempre per un solo motivo: la ricerca nativa non tiene il passo con un catalogo grande. E in effetti la ricerca migliora. Quello che a volte nessuno controlla è cosa succede al resto del negozio, in particolare al carrello e al checkout, quando quell'indice esterno deve restare aggiornato con lo stock e la disponibilità del catalogo, che cambiano a ogni vendita.

Il motivo per cui questo pezzo viene spesso trascurato è semplice: nella demo, con pochi ordini, non si nota nulla. Il problema emerge sotto carico reale, quando più ordini arrivano nello stesso momento, e in quel momento il cliente sta già pagando: non è il posto in cui si vuole scoprire un collo di bottiglia.

Cosa deve succedere quando un cliente cambia la quantità nel carrello

Con un motore di ricerca esterno, ogni prodotto vive due volte: una riga nel database di PrestaShop, e un "documento" dentro l'indice del motore di ricerca, con i campi che servono per trovarlo e per filtrarlo (nome, prezzo, categorie, disponibilità, e altro). Quando un cliente aggiunge un prodotto al carrello, cambia la quantità, o un ordine viene confermato, la disponibilità di quel prodotto cambia, e il documento nell'indice di ricerca deve rifletterlo, altrimenti un altro visitatore potrebbe vedere come disponibile un prodotto appena esaurito.

Il modo più semplice per farlo, e anche il più costoso, è ricostruire il documento intero da zero ogni volta: rileggere nome, descrizione, prezzo, categorie, immagini e tutto il resto dal database, per aggiornare tre numeri (quantità, disponibilità, ordine di visualizzazione per disponibilità). Se questa ricostruzione parte una volta per ogni riga di ordine, un ordine con cinque prodotti diversi la fa partire cinque volte, in un momento in cui il cliente sta aspettando la conferma di pagamento.

I numeri reali

Misurato su PrestaShop 9.0.0, con due negozi collegati a Elasticsearch, un ordine di cinque righe che ricostruiva il documento completo per ogni riga costava 243 interrogazioni al database e 229 millisecondi, solo per spostare tre numeri nell'indice di ricerca. Non è il tempo dell'intero checkout, è il tempo di un solo passaggio dentro di esso, quello che tiene aggiornato l'indice.

Con un percorso dedicato che aggiorna solo i campi che sono davvero cambiati (quantità, disponibilità, ordine per disponibilità), invece di ricostruire tutto il documento, lo stesso ordine sugli stessi negozi è sceso a 9 interrogazioni e tra 16 e 47 millisecondi. Stessa operazione, stesso risultato finale nell'indice: cambia solo quanto lavoro viene fatto per ottenerlo.

La differenza tecnica è semplice da spiegare anche a chi non scrive codice: un motore di ricerca esterno offre normalmente due modi per aggiornare un documento. Il primo è "sostituiscilo tutto", utile quando cambia davvero qualcosa di strutturale come il nome o il prezzo. Il secondo è "aggiorna solo questi campi", pensato apposta per il caso molto più frequente in cui cambia solo la disponibilità. Usare sempre il primo modo, anche quando serve solo il secondo, è la causa più comune di un checkout che rallenta proprio quando il negozio vende di più.

Perché succede quasi sempre nello stesso punto

In PrestaShop, l'evento che segnala un cambio di quantità durante l'ordine può scattare una volta per ogni riga dell'ordine, non una volta per l'intero ordine. È facile scrivere il codice che ascolta questo evento pensando "è solo un aggiornamento", senza notare che su un ordine con molte righe, o durante un picco di vendite con molti ordini contemporanei, quella singola scelta si moltiplica per il numero di righe e per il numero di ordini in corso nello stesso momento. Un modulo di ricerca che sembra veloce nei test con un ordine alla volta può comportarsi in modo molto diverso durante un Black Friday con centinaia di checkout simultanei.

Cosa chiedere se avete già un motore esterno

• Chiedete al vostro modulo di ricerca o al vostro integratore se un cambio di quantità nel carrello aggiorna solo i campi di stock, o ricostruisce l'intero documento del prodotto.
• Fate un test con un ordine di più righe durante un momento di traffico basso e guardate il log lento del database (slow query log) durante il checkout: se vedete decine di interrogazioni ripetute per lo stesso prodotto, il sintomo è proprio questo.
• Se gestite un negozio B2B o all'ingrosso con carrelli di molte righe, questo problema pesa in proporzione: un carrello di trenta righe con un aggiornamento completo per riga è sei volte più lento di uno di cinque righe, mentre con un aggiornamento mirato la differenza è molto più piccola.
• Non è un motivo per rinunciare a un motore di ricerca esterno: la ricerca su un catalogo grande ne ha comunque bisogno. È un motivo per verificare come è stata scritta l'integrazione tra il carrello e l'indice.

In sintesi

Un motore di ricerca esterno non rallenta il checkout di per sé. Rallenta il checkout un'integrazione che ricostruisce l'intero documento di ricerca per un cambiamento che riguarda solo tre numeri. La differenza misurata, da 243 interrogazioni e 229 millisecondi a 9 interrogazioni e 16-47 millisecondi sullo stesso ordine, è il tipo di lavoro che in cll_essearch abbiamo fatto separando gli aggiornamenti di stock da quelli strutturali su Elasticsearch, OpenSearch e Meilisearch. Se il vostro negozio usa un motore esterno e il checkout si allunga proprio quando le vendite aumentano, è questo il punto da controllare per primo.

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