Een filterpaneel dat vier seconden nodig heeft om te antwoorden, wordt als kapot ervaren. Het probleem is zelden de module zelf: het komt van de manier waarop de query’s zijn opgebouwd en van wat de database moet doorlopen om te antwoorden.
Hier hoe u de oorzaak lokaliseert voor u ook maar iets verandert.
Meten voor u veronderstelt
Drie metingen, in deze volgorde.
De concrete responstijd van een filterquery, gemeten in het netwerktabblad van de browser op uw grootste categorie met twee of drie actieve filters. Noteer de waarde: dat is uw vertrekpunt.
Het aandeel van die tijd doorgebracht in de database. Activeer de profilering van PrestaShop in een testomgeving: ze toont het aantal uitgevoerde query’s en hun gecumuleerde duur. Vertegenwoordigt de databasetijd 80% van het totaal, dan is het zinloos elders te kijken.
Het aantal uitgevoerde query’s. Dat is vaak de openbaring: een gefilterde categoriepagina die driehonderd query’s uitvoert, heeft een ontwerpprobleem, geen probleem van servercapaciteit.
Dat derde punt verdient aandacht. Een vermenigvuldiging van de query’s signaleert doorgaans een tellerberekening waarde per waarde, of het laden van producten een voor een in een lus.
De vier hoofdoorzaken
De joins op de attribuuttabellen. Filteren op drie attributen veronderstelt de waardetabellen meermaals te joinen. Op een catalogus van twintigduizend combinaties produceren die joins aanzienlijke tussenresultaten.
De berekening van de tellers. Het aantal resultaten achter elke waarde tonen veronderstelt een aggregatie per waarde. Op een paneel met zestig waarden kan dat zestig aggregaties betekenen bij elke selectiewijziging.
De totaaltelling voor de paginering. De regels van een brede selectie tellen kost bijna evenveel als ze lezen.
De ontbrekende indexen. Op de koppeltabellen tussen producten, attributen en categorieën verandert een afwezige index een opzoeking in een volledige tabeldoorloop.
De indexen diagnosticeren
Dit is de meest rendabele en snelste verificatie.
Haal de traagste filterquery op uit het slow-query-log van uw database, en voer ze uit voorafgegaan door het sleutelwoord voor de uitleg van het uitvoeringsplan.
Drie signalen om in het resultaat te herkennen.
Een toegangstype dat op een volledige doorloop wijst op een omvangrijke tabel. Dat is het teken van een ontbrekende of onbruikbare index.
Een aantal onderzochte regels dat niet in verhouding staat tot het aantal teruggegeven regels. Tweehonderdduizend regels onderzoeken om er veertig terug te geven, wijst erop dat het filteren na het lezen gebeurt in plaats van via de index.
De vermelding van een tijdelijke sortering of een tijdelijke tabel, die signaleert dat de database de sortering niet via een index kan afhandelen en een tussenresultaat moet materialiseren.
Praktisch punt: de nuttige indexen op deze tabellen betreffen vaak gecombineerde kolommen, en hun volgorde telt. Een index op product dan attribuut dient niet dezelfde query’s als een index op attribuut dan product.
AJAX Facetfilters PrestaShopDe facetnavigatie die snel filtert en juist indexeert€99,00
Het werk verminderen in plaats van versnellen
Voor de technische optimalisatie hebben drie functionele beslissingen vaak meer effect.
Het aantal filters verminderen. Elk filterbaar attribuut voegt potentiële joins en te berekenen tellers toe. Twaalf filters waarvan er vier worden gebruikt, kosten driemaal te veel.
Afzien van de tellers op de grote catalogi, of ze alleen berekenen op de meest gebruikte filters. Het verloren comfort is echt, de tijdwinst ook.
De combinatiediepte beperken. Boven drie gelijktijdige filters worden de selecties zeldzaam en duur. U kunt een plafond instellen zonder dat iemand het merkt.
Deze drie maatregelen vragen geen enkele ontwikkeling en laten zich in een namiddag testen.
De speciale index
Wanneer de voorgaande maatregelen niet volstaan, bestaat het structurele antwoord erin de catalogustabellen niet meer te bevragen op het moment van het filteren.
Het principe: een platte, voorberekende tabel die voor elk product zijn filterbare waarden, zijn prijs, zijn beschikbaarheid en zijn categorieën bevat. Het filteren wordt een eenvoudige query op één enkele geïndexeerde tabel.
Drie implementatiepunten.
De bijwerking moet zich activeren bij elke wijziging van product, prijs of voorraad. Een gedesynchroniseerde index toont producten die niet meer bestaan of verbergt nieuwigheden.
De volledige herbouw moet mogelijk blijven, en haar uitvoeringstijd gemeten: op een grote catalogus kan ze meerdere minuten duren en mag ze niet in het piekuur draaien.
De massale activering. Een catalogusimport die tienduizend producten wijzigt, mag geen tienduizend afzonderlijke herbouwen activeren. Voorzie een uitgestelde modus.
De cache, en zijn grenzen
De cache is nuttig en hij wordt op dit onderwerp vaak slecht ingezet.
De filterresultaten cachen werkt goed wanneer de gevraagde combinaties weinig talrijk en herhaald zijn. Dat is het geval op de meeste winkels: enkele tientallen combinaties dekken het merendeel van het verkeer.
Twee grenzen om te kennen. De cache behandelt het eerste bezoek niet van elke combinatie, dat traag blijft. En hij moet worden geïnvalideerd bij elke voorraad- of prijswijziging, anders toont u foute informatie.
Op de beschikbaarheidsgegevens moet de cacheduur kort blijven, enkele minuten, wat zijn nut sterk vermindert. Een gangbare aanpak bestaat erin de lijst van overeenkomende producten te cachen en prijs en voorraad live op te halen.
De verificaties aan infrastructuurzijde
Drie punten die niet van de code afhangen.
Het geheugen toegewezen aan de database. Een database die haar indexen niet in het geheugen kan houden, herleest ze bij elke query vanaf de schijf. Dat is de meest voorkomende oorzaak van veralgemeende traagheid na een catalogusgroei.
De configuratie van de querycache en de buffers, aan te passen aan de daadwerkelijke omvang van uw gegevens in plaats van bij de standaardwaarden van de installatie te blijven.
De concurrerende resources. Een catalogusexport of een geplande taak die tegelijk met de verkeerspiek draait, verslechtert alles. Verschuif wat verschoven kan worden.
De volledige aanpak
Zes stappen, in deze volgorde van afnemend rendement.
1. Meet de responstijd en het aantal query’s.
2. Controleer de indexen met een uitvoeringsplan op de traagste query.
3. Beperk het aantal aangeboden filters tot de gebruikte.
4. Deactiveer of beperk de tellers als de catalogus omvangrijk is.
5. Zet een cache op voor de frequente combinaties.
6. Overweeg een speciale index als de eerste vijf stappen niet volstaan.
Methodepunt: meet na elke stap. Meerdere stappen tegelijk nemen ontneemt u het inzicht welke het effect heeft geproduceerd, en dus waar u de volgende keer de inspanning moet concentreren.
De AJAX Facetfilters module voor PrestaShop integreert deze mechanismen op PrestaShop 8 en 9: voorberekende speciale index met incrementele bijwerking, resultatentellers in één enkele aggregatie, cache per combinatie met invalidatie bij voorraad- en prijswijzigingen, en instelbare beperking van de combinatiediepte.
