Seite 1 von 1

Geschwindigkeitseinbuße durch Facettensuche / viele Artikel

BeitragVerfasst: Di 20. Feb 2018, 17:26
von Muffelwild
Hi,

teste grade eine frische Installation mit neuen Artikeldaten... Knapp 20.000 Kategorien mit knapp 300.000 Artikeln. Läuft auch ziemlich schnell der Shop wenn man das normale Kategorienmenü raus schmeißt :lol: Aber jetzt habe Facettenmerkmale hinzugefügt. Bei jedem Artikel soll es zwei geben:

als Beispiel:
Artikel ist entweder für vorne oder hinten und dann noch entweder links oder rechts. somit sind das schon mal 600t Zuweisungen. Jetzt will ich aber auch die Möglichkeit dem Kunden geben wieder alle anzuzeigen und habe jedem Merkmal noch den Punkt "alle anzeigen" gegeben. Sind also jetzt ~1,2 Millionen Zuweisungen/Zeilen in der Datenbank. Das ist dann wohl doch etwas viel und der Aufruf einer Kategorie dauert so 20-30 Sekunden.

Hat jemand eine Idee wie man das optimieren könnte? In den Kopf käme mir zum Beispiel Checkboxen. Das würde schon mal 600t Zeilen sparen. Nur ob es das deutlich schneller machen würde?

Re: Geschwindigkeitseinbuße durch Facettensuche / viele Arti

BeitragVerfasst: Di 20. Feb 2018, 17:41
von Muffelwild
Kann man Beiträge nicht editieren?

Habe jetzt mal den Punkt "alle Anzeigen" und bei der zweiten Auswahl noch einen Punkt gelöscht. So könnte man es lassen wenn man einen Link "Facettensuche zurücksetzen" auf die Kategorie setzt, aber so habe ich immer noch 4-5 Sekunden Ladezeit pro Klick auf eine Auswahl.

Re: Geschwindigkeitseinbuße durch Facettensuche / viele Arti

BeitragVerfasst: Do 22. Feb 2018, 19:39
von Magnus
Klar, Ideen für die Optimierung gibts genügend:

Als erstes würde ich versuchen rauszufinden, was den so lange dauert:
- sind es wirklich die Datenbankabfragen
- oder eher der Zusammenbau der Seite in PHP
- oder die Übertragung der großen Menge HTML zum Client
- oder das Rendern des HTML im Browser?

Wenn das dann eingegrenzt ist, geht man die Dinge an, die sehr lange dauern und gut zu beheben sind, allerdings treffen auf die wenigsten Dinge beide Eigenschaften zu :-) :
- bei der Datenbank vielleicht Indexe setzen, einfache Abfragen in vordefinierte Statements oder StoredProcedures umbauen, vielleicht sogar die Tabellen auf mehrere aufteilen
- beim Zusammenbau der Seite wirds schwieriger, hier werden z.B. in Schleifen Abfragen für Unterkategorien erstellt, das wird umso langsamer je mehr Kategorien und Unterkategorien vorhanden sind. Der Umbau führt meist über ein neues Konzept für den Programmablauf zu komplett neuem ProgrammCode. Je nachdem ist Caching auch eine Möglichkeit, die Performance in diesem Bereich zu steigern.
- Übertragung zum Client beschleunigen beginnt bei der Komprimierung der Seite und endet bei einem performanten Server.
- Rendern des HTML im Browser fängt mit validem HTML an und führt über viele kleinere Stellschrauben, wie Reduzierung des HTML, Vereinfachen des CSS, usw.

So insgesamt würde ich eher dazu tendieren den Shop einfach kleiner zu machen, vielleicht lassen sich die Produkte ja auf mehrere shops verteilen.

Ansonsten würde ich mal davon ausgehen, dass 300.000 Artikel und 20.000 Kategorien ne Nummer zu groß ist. Vielleicht lässt sich ja insgesamt über den Aufbau des Shops noch was machen, z.B. nicht alle Artikel einzeln aufführen sondern vom Kunden konfigurieren lassen.

Insgesamt ist es eigentlich nur das Suchen nach dem optimalen Kompromiss.

viele Grüße

Magnus

Re: Geschwindigkeitseinbuße durch Facettensuche / viele Arti

BeitragVerfasst: Mo 26. Feb 2018, 15:48
von mmaass
So auf die schnelle fällt mir da erst mal nur ein, dass Du direkt in die Funktion schauen kannst.
getFacettensucheFilterAuspraegungenForKategorie($kategorieId, $languageId = false, $artikelIds = false, $kundengruppeObject = false)

In includes/functions.facettensuche.inc.php

Und da eben guckst, ob Du vielleicht auf den ein oder anderen join verzichten kannst, wenn Du nicht auf alle Funktionen zurückgreifst.
Autofilter z.B.

Schlussendlich musst Du die Last der 600.000 runter bekommen, so dass in so wenig wie möglich Verknüpfungen rein geschaut werden muss.
Indexiert müsste schon alles sein.

Generell sind die vielen Mengen an Daten ja schon eine Last. Da muss man generell jegliche Funktionen, die man nicht nutzt, raus schmeissen, gerade auch bei den Artikeln, da hier durch die Grundfunktionalität immer viel bei ist, was man vielleicht nicht benötigt. Insbesondere die Merkmalkombinationan etc.