Waarom de kassa van PrestaShop trager wordt als u een externe zoekmotor toevoegt

Een bijwerking die u niet verwacht

Elasticsearch, OpenSearch of Meilisearch wordt op PrestaShop bijna altijd om één reden geïnstalleerd: de eigen zoekfunctie kan een grote catalogus niet meer bijbenen. En het zoeken wordt inderdaad beter. Wat minder vaak wordt gecontroleerd, is wat er gebeurt met de rest van de webwinkel, in het bijzonder met de winkelwagen en de kassa, wanneer die externe index gesynchroniseerd moet blijven met de voorraad en de beschikbaarheid, die bij elke verkoop veranderen.

Dat dit deel vaak onopgemerkt blijft, heeft een eenvoudige reden: in een demo, met een handvol bestellingen, is er niets te zien. Het probleem verschijnt onder echte belasting, wanneer meerdere bestellingen tegelijk binnenkomen, en op dat moment is de klant al aan het betalen. Dat is niet de plek waar u een knelpunt wilt ontdekken.

Wat er moet gebeuren als een klant een hoeveelheid in zijn winkelwagen wijzigt

Met een externe zoekmotor bestaat elk product twee keer: één rij in de database van PrestaShop en één “document” in de index van de zoekmotor, met de velden die nodig zijn om het te vinden en te filteren (naam, prijs, categorieën, beschikbaarheid enzovoort). Wanneer een klant een product aan de winkelwagen toevoegt, een hoeveelheid wijzigt of een bestelling wordt bevestigd, verandert de beschikbaarheid van dat product, en het document in de index moet daar rekening mee houden. Anders kan een andere klant een product als beschikbaar zien dat net is uitverkocht.

De eenvoudigste manier om dat te doen, en ook de duurste, is het hele document telkens opnieuw opbouwen: naam, beschrijving, prijs, categorieën, afbeeldingen en al het andere opnieuw uit de database lezen om drie cijfers bij te werken (hoeveelheid, beschikbaarheid, sorteervolgorde op basis van beschikbaarheid). Als die heropbouw één keer per bestelregel wordt gestart, wordt ze bij een bestelling van vijf verschillende producten vijf keer gestart, precies op het moment dat de klant wacht op de bevestiging van zijn betaling.

De echte cijfers

Gemeten op PrestaShop 9.0.0, met twee webwinkels die met Elasticsearch zijn verbonden, kostte een bestelling van vijf regels die voor elke regel het volledige document opnieuw opbouwde 243 SQL-query's en 229 milliseconden, alleen om drie cijfers in de zoekindex te verplaatsen. Dat is niet de tijd van de volledige kassa, maar de tijd van één enkele stap daarbinnen, de stap die de index gesynchroniseerd houdt.

Met een speciaal pad dat alleen de werkelijk gewijzigde velden bijwerkt (hoeveelheid, beschikbaarheid, volgorde op beschikbaarheid) in plaats van het hele document opnieuw op te bouwen, daalde dezelfde bestelling op dezelfde webwinkels naar 9 query's en 16 tot 47 milliseconden. Dezelfde bewerking, hetzelfde eindresultaat in de index: alleen de hoeveelheid werk die ervoor nodig is, verandert.

Het technische verschil is makkelijk uit te leggen, ook aan iemand die geen code schrijft: een externe zoekmotor biedt normaal gesproken twee manieren om een document bij te werken. De eerste, “volledig vervangen”, is bedoeld voor wanneer er echt iets structureels verandert, zoals de naam of de prijs. De tweede, “alleen deze velden bijwerken”, is bedoeld voor het veel vaker voorkomende geval waarin alleen de beschikbaarheid verandert. Altijd de eerste gebruiken, ook als de tweede volstaat, is de meest voorkomende oorzaak van een kassa die juist trager wordt wanneer de webwinkel meer verkoopt.

Waarom dit bijna altijd op dezelfde plek gebeurt

In PrestaShop kan de gebeurtenis die een wijziging van de hoeveelheid tijdens een bestelling meldt, één keer per bestelregel worden afgevuurd, en niet één keer voor de hele bestelling. Het is gemakkelijk om de code die naar deze gebeurtenis luistert te schrijven met de gedachte “het is maar een update”, zonder te merken dat deze keuze bij een bestelling met veel regels, of bij een verkooppiek met veel gelijktijdige bestellingen, wordt vermenigvuldigd met het aantal regels en met het aantal bestellingen dat op hetzelfde moment loopt. Een zoekmodule die in een test met één bestelling tegelijk snel lijkt, kan zich tijdens Black Friday met honderden gelijktijdige bestelprocessen heel anders gedragen.

Wat u moet vragen als u al een externe zoekmotor hebt

• Vraag aan uw zoekmodule of uw integrator of een wijziging van de hoeveelheid in de winkelwagen alleen de voorraadvelden bijwerkt, of het hele productdocument opnieuw opbouwt.
• Doe een test met een bestelling van meerdere regels op een rustig moment en houd het logboek van trage query's van de database in de gaten tijdens de kassa: ziet u tientallen herhaalde query's voor hetzelfde product, dan is dit precies dit symptoom.
• Beheert u een B2B-webwinkel of een groothandel met winkelwagens van veel regels, dan schaalt dit probleem slecht: een winkelwagen van dertig regels met een volledige heropbouw per regel is zes keer trager dan een winkelwagen van vijf regels, terwijl het verschil bij een gerichte update veel kleiner is.
• Dit is geen reden om af te zien van een externe zoekmotor: een grote catalogus heeft er altijd een nodig voor het zoeken. Het is een reden om te controleren hoe de integratie tussen de winkelwagen en de index werkelijk is geschreven.

Samengevat

Een externe zoekmotor maakt de kassa niet op zichzelf trager. Wat de kassa trager maakt, is een integratie die het hele zoekdocument opnieuw opbouwt voor een wijziging die maar drie cijfers betreft. Het gemeten verschil, van 243 query's en 229 milliseconden naar 9 query's en 16 tot 47 milliseconden voor dezelfde bestelling, komt overeen met het werk dat wij in cll_essearch hebben gedaan door voorraadupdates te scheiden van structurele updates op Elasticsearch, OpenSearch en Meilisearch. Gebruikt uw webwinkel een externe zoekmotor en wordt de kassa trager precies wanneer de verkoop aantrekt, dan is dit het eerste wat u moet controleren.

Elasticsearch-zoekfunctie & gefacetteerde navigatieRazendsnelle zoekfunctie met typfouttolerantie en moderne gefacetteerde navigatie in een venster, met de…€ 99,99Bekijk product