Ein Filterpanel, das vier Sekunden zum Antworten braucht, wird als kaputt wahrgenommen. Das Problem ist selten das Modul selbst: Es kommt von der Art, wie die Abfragen aufgebaut sind, und von dem, was die Datenbank durchlaufen muss, um sie zu beantworten.
So lokalisieren Sie die Ursache, bevor Sie irgendetwas ändern.
Messen statt vermuten
Drei Messungen, in dieser Reihenfolge.
Die reale Antwortzeit einer Filteranfrage, gemessen im Netzwerk-Tab des Browsers auf Ihrer größten Kategorie mit zwei oder drei aktiven Filtern. Notieren Sie den Wert: Das ist Ihr Ausgangspunkt.
Der Anteil dieser Zeit, der in der Datenbank verbracht wird. Aktivieren Sie das Profiling von PrestaShop in einer Testumgebung: Es zeigt die Anzahl der ausgeführten Abfragen und ihre kumulierte Dauer. Wenn die Datenbankzeit 80 % des Gesamten ausmacht, ist es sinnlos, woanders zu suchen.
Die Anzahl der ausgeführten Abfragen. Das ist oft die Offenbarung: Eine gefilterte Kategorieseite, die dreihundert Abfragen ausführt, hat ein Designproblem, kein Serverleistungsproblem.
Dieser dritte Punkt verdient Aufmerksamkeit. Eine Vervielfachung der Abfragen signalisiert in der Regel eine Zählerberechnung Wert für Wert oder ein Laden der Produkte einzeln in einer Schleife.
Die vier Hauptursachen
Die Joins auf den Attributtabellen. Auf drei Attribute zu filtern bedeutet, die Wertetabellen mehrfach zu joinen. Bei einem Katalog von zwanzigtausend Varianten erzeugen diese Joins erhebliche Zwischenmengen.
Die Zählerberechnung. Die Anzahl der Ergebnisse hinter jedem Wert anzuzeigen bedeutet eine Aggregation pro Wert. Bei einem Panel mit sechzig Werten können das sechzig Aggregationen bei jeder Auswahländerung sein.
Die Gesamtzählung für die Paginierung. Die Zeilen einer breiten Auswahl zu zählen kostet fast so viel wie sie zu lesen.
Die fehlenden Indizes. Auf den Verknüpfungstabellen zwischen Produkten, Attributen und Kategorien verwandelt ein fehlender Index eine Suche in einen vollständigen Tabellendurchlauf.
Die Indizes diagnostizieren
Das ist die rentabelste und schnellste Prüfung.
Holen Sie die langsamste Filterabfrage aus dem Slow-Query-Log Ihrer Datenbank und führen Sie sie mit vorangestelltem Ausführungsplan-Schlüsselwort aus.
Drei Signale, die im Ergebnis zu erkennen sind.
Ein Zugriffstyp, der einen vollständigen Durchlauf anzeigt, auf einer großen Tabelle. Das ist das Zeichen eines fehlenden oder unbrauchbaren Index.
Eine Anzahl untersuchter Zeilen ohne jedes Verhältnis zur Anzahl zurückgegebener Zeilen. Zweihunderttausend Zeilen zu untersuchen, um vierzig zurückzugeben, zeigt, dass das Filtern nach dem Lesen statt über den Index erfolgt.
Die Erwähnung einer temporären Sortierung oder einer temporären Tabelle, die signalisiert, dass die Datenbank die Sortierung nicht per Index erfüllen kann und ein Zwischenergebnis materialisieren muss.
Praktischer Punkt: Die nützlichen Indizes auf diesen Tabellen betreffen oft kombinierte Spalten, und ihre Reihenfolge zählt. Ein Index auf Produkt, dann Attribut dient nicht denselben Abfragen wie ein Index auf Attribut, dann Produkt.
AJAX-Facettenfilter für PrestaShopDie Facettennavigation, die schnell filtert und richtig indexiert99,00€
Die Arbeit reduzieren statt sie zu beschleunigen
Vor der technischen Optimierung haben drei funktionale Entscheidungen oft mehr Wirkung.
Die Anzahl der Filter reduzieren. Jedes filterbare Attribut fügt potenzielle Joins und zu berechnende Zähler hinzu. Zwölf Filter, von denen vier genutzt werden, kosten dreimal zu viel.
Auf Zähler bei großen Katalogen verzichten, oder sie nur für die meistgenutzten Filter berechnen. Der verlorene Komfort ist real, der Zeitgewinn auch.
Die Kombinationstiefe begrenzen. Jenseits von drei gleichzeitigen Filtern werden die Auswahlen selten und teuer. Sie können deckeln, ohne dass es jemand bemerkt.
Diese drei Maßnahmen erfordern keine Entwicklung und lassen sich an einem Nachmittag testen.
Der dedizierte Index
Wenn die vorherigen Maßnahmen nicht ausreichen, besteht die strukturelle Antwort darin, die Katalogtabellen zum Filterzeitpunkt nicht mehr abzufragen.
Das Prinzip: eine flache, vorberechnete Tabelle, die für jedes Produkt seine filterbaren Werte, seinen Preis, seine Verfügbarkeit und seine Kategorien enthält. Das Filtern wird zu einer einfachen Abfrage auf einer einzigen indizierten Tabelle.
Drei Umsetzungspunkte.
Die Aktualisierung muss bei jeder Änderung von Produkt, Preis oder Bestand ausgelöst werden. Ein desynchronisierter Index zeigt Produkte, die nicht mehr existieren, oder verbirgt Neuheiten.
Der vollständige Neuaufbau muss möglich bleiben, und seine Ausführungszeit gemessen: Bei einem großen Katalog kann er mehrere Minuten dauern und darf nicht zur Stoßzeit laufen.
Die Massenauslösung. Ein Katalogimport, der zehntausend Produkte ändert, darf nicht zehntausend Einzelneuaufbauten auslösen. Sehen Sie einen verzögerten Modus vor.
Der Cache und seine Grenzen
Der Cache ist nützlich und wird bei diesem Thema oft falsch eingesetzt.
Filterergebnisse zu cachen funktioniert gut, wenn die angefragten Kombinationen wenige und wiederholt sind. Das ist bei den meisten Shops der Fall: Einige Dutzend Kombinationen decken das Wesentliche des Traffics ab.
Zwei Grenzen, die man kennen muss. Der Cache behandelt nicht den ersten Besuch jeder Kombination, der langsam bleibt. Und er muss bei jeder Bestands- oder Preisänderung invalidiert werden, sonst zeigen Sie falsche Informationen an.
Bei Verfügbarkeitsdaten muss die Cache-Dauer kurz bleiben, einige Minuten, was seinen Nutzen stark reduziert. Ein gängiger Ansatz besteht darin, die Liste der passenden Produkte zu cachen und Preis und Bestand live abzurufen.
Die infrastrukturseitigen Prüfungen
Drei Punkte, die nicht den Code betreffen.
Der der Datenbank zugewiesene Speicher. Eine Datenbank, die ihre Indizes nicht im Speicher halten kann, liest sie bei jeder Abfrage von der Festplatte neu. Das ist die häufigste Ursache allgemeiner Langsamkeit nach einem Katalogwachstum.
Die Konfiguration des Abfrage-Caches und der Puffer, anzupassen an die reale Größe Ihrer Daten, statt bei den Standardwerten der Installation zu bleiben.
Die konkurrierenden Ressourcen. Ein Katalogexport oder eine geplante Aufgabe, die gleichzeitig mit der Traffic-Spitze läuft, verschlechtert alles. Verschieben Sie, was sich verschieben lässt.
Das vollständige Vorgehen
Sechs Schritte, in dieser Reihenfolge abnehmender Rentabilität.
1. Messen Sie die Antwortzeit und die Anzahl der Abfragen.
2. Prüfen Sie die Indizes mit einem Ausführungsplan auf der langsamsten Abfrage.
3. Reduzieren Sie die angebotenen Filter auf die tatsächlich genutzten.
4. Deaktivieren oder begrenzen Sie die Zähler, wenn der Katalog groß ist.
5. Richten Sie einen Cache für die häufigen Kombinationen ein.
6. Erwägen Sie einen dedizierten Index, wenn die ersten fünf Schritte nicht ausreichen.
Methodischer Punkt: Messen Sie nach jedem Schritt. Mehrere Schritte auf einmal zu gehen nimmt Ihnen das Wissen, welcher die Wirkung erzeugt hat, und damit das Wissen, wo Sie beim nächsten Mal den Aufwand konzentrieren sollen.
Das AJAX-Facettenfilter-Modul für PrestaShop integriert diese Mechanismen auf PrestaShop 8 und 9: vorberechneter dedizierter Index mit inkrementeller Aktualisierung, Ergebniszähler in einer einzigen Aggregation, Cache pro Kombination mit Invalidierung bei Bestands- und Preisänderungen und parametrierbare Begrenzung der Kombinationstiefe.
