Also Purchased verursacht slow query

[demoncleaner]

Vorab - da ich da in der Vergangenheit schon öfter mal falsch verstanden wurde - das hier ist ein Erfahrungsbericht und im Prinzip kein Hilfegesuch. Ich bin mir nicht sicher ob das eine Art Bug ist, daher gehe ich nicht hin und trage es direkt in den Bugtracker ein, sondern möchte erstmal ein paar Experten beurteilen lassen, ob es sein kann, dass ich hier richtig liege.

Also: Im betroffenen Shop hatten wir heute aufgrund einer Newsletteraktion deutlich mehr Zugriffe als sonst. Was dazu führte, dass der Shop langsam wurde und vor allem die Produktseiten ewig luden. Ich dachte zunächst es wäre mein Fehler und ich hätte eine schlechte query irgendwo eingebaut, die das verursacht.

Ein Blick in das slowquery log wies die function getAlsoPurchased als Übeltäter aus. Daran hatte ich nicht rumgefummelt.
Abgesehen davon, dass ich irretiert war, weil der Proivider mir mitteilte, dass das Datenbankformat nicht für so viele Zugriffe ausgelegt wäre (er sprach von InnoDB womit ich an meine Grenzen stoße) hab ich dann in filenames.php kurzerhand die also_purchased_products.php auskommentiert und der Spuk war vorbei.

Die function sieht so aus:

Code: PHP  [Auswählen]

SELECT ".$this->default_select."
                                     FROM ".TABLE_ORDERS_PRODUCTS." op
                                     JOIN ".TABLE_PRODUCTS." p
                                          ON p.products_id = op.products_id
                                             AND p.products_status = '1'
                                             AND p.products_id != '".(int)$pID."'
                                     JOIN ".TABLE_PRODUCTS_DESCRIPTION." pd
                                          ON pd.products_id = p.products_id
                                             AND pd.language_id = '".(int) $_SESSION['languages_id']."'
                                             AND trim(pd.products_name) != ''
                                    WHERE op.orders_id IN (SELECT *
                                                             FROM (SELECT orders_id
                                                                     FROM ".TABLE_ORDERS_PRODUCTS."
                                                                    WHERE products_id = '".(int)$pID."'
                                                                 GROUP BY orders_id
                                                                 ORDER BY orders_id DESC
                                                                    LIMIT ".MAX_DISPLAY_ALSO_PURCHASED_ORDERS."
                                                                  ) o
                                                           )
                                          ".PRODUCTS_CONDITIONS_P."
                                 GROUP BY p.products_id
                                 ORDER BY op.orders_id DESC
                                    LIMIT ".MAX_DISPLAY_ALSO_PURCHASED

Ich nutze das Ganze "Kunden kauften auch" sowieso nicht. Daher für mich erstmal verkraftbar.
Ich frage mich (euch) aber nun... kann es denn sein, dass die o.g. function tatsächlich ein Problem darstellt, wenn in der orders_products sagen wir mal... 300.000 Einträge liegen?

Wäre ein probates Mittel, bei einem Shop mit hohem Bestellaufkommenn z.B. Bestellungen nur aus 2,3 Vorjahren vorzuhalten?
Mich interessiert wie ihr das seht bzw. wie iher das evtl. macht.
Löscht ihr in diesem (oder einem anderen) Zusammenhang alte Bestellungen um g.g.F. die Performance zu verbessern?

Linkback: https://www.modified-shop.org/forum/index.php?topic=42271.0

[DerNachbar]

Ich habe ein ähnliches Problem mit langen Ladezeiten bei ein paar bestimmten Artikeln, auf den viele andere Artikel im Crossselling (Empfehlungen) verlinken. Bis diese Artikel geladen sind, dauert es dann 3-5 Sekunden. Habe die letzten Tage schon angefangen Artikel aus dem Crossselling zu entfernen, um die betroffenen Artikel wieder schneller laden zu lassen. Vielleicht gibt es da ja einen Zusammenhang mit deinem Problem, was auch das Crossselling betrifft.  Wer weiss. Wollte es nur als Randnotiz hier lassen.

[Timm]

Moin

Weiß nicht, ob sich in der letzten Zeit was an den Dateien geändert hat. Falls ja, wäre die Shopversion wichtig.

Gruß Timm

[demoncleaner]

Sorry, Timm hast recht.

Es Ist modified 2.0.6.0

@DerNachbar: Wie viele Artikel hast du denn vercross-selled?
Ich glaube eher, dass hat hier nicht direkt mit meinem Problem zu tun. Meine Frage war ja im Prinzip: Kann die Anzahl der Bestellungen - auf die ich ja keinen direkten Einfluss habe, also anders als beim Cross-Selling - u.U. zum Problem für die getAlsoPurchased Funktion werden?

[DerNachbar]

Bei z.B. einem der problematischen Artikel habe ich gerade 525 Artikel noch im XSell. Waren mal 775. Lösche halt ab und an fleissig raus. Wie gesagt weiss ich nicht ob das im geringsten was damit zu tun haben könnte, was dein Problem betrifft.

[noRiddle (revilonetz)]

AlsoPurchased ist in der Tat ein Performance-Killer wenn sich bereits sehr viele Bestellungen in der Datenbank befinden.
Das muß man sich bei Gelegenheit mal genauer ansehen.
Allerdings kann man das Modul nicht ausschalten indem man in der /includes/filenames.php einfach die Definition der Konstanten für die DB-Tabelle auskommentiert. Das führt zu massenhaft Log-Einträgen à la
"undefined constant FILENAME_ALSO_PURCHASED_PRODUCTS".

Die Ausführung des Moduls kann man unterbinden, indem man man im Backend bei
Konfiguration => Maximum Werte => "Ebenfalls gekauft"
den Wert auf 0 stellt. (*EDIT* Backend Menu-Punkt korrigiert *END_EDIT*)
Das hättest du, demoncleaner, wenn du schon selbst eruierst und dann im Code rumfummelst, auch feststellen können, nämlich wenn du da wo du die Query gefunden hast auch diesen Code gelesen hättest:

Code: PHP  [Auswählen]

    if (MAX_DISPLAY_ALSO_PURCHASED <= 0) {
      return array();
    }

Das Problem hatte ich im Übrigen in Ticket #1792 vor ca. 2 Jahren bereits angesprochen und es ist zumindest insoweit gefixt worden, als daß man mittels der genannten Einstellung die Ausführung verhindern kann.

Ich wundere mich immer wieder wie leichtfertig User die mit Mühe eingebauten Möglichkeiten Update-Sicherheit zu gewährleisten über Bord werfen, ganz zu schweigen von solch von Unwissenheit geprägten Vorgehensweisen wie einfach eine Code-Stelle auszukommentieren. Nur nicht vorher fragen.

Gruß,
noRiddle

[demoncleaner]

Erstmal besten Dank noRiddle für die Bestätigung meiner Vermutung. Mehr hab ich gar nicht gewollt.

Und nur noch so als kleine Anmerkung und Erklärung am Rande damit du dich nicht weiter wundern musst:

... wie leichtfertig User die mit Mühe eingebauten Möglichkeiten Update-Sicherheit zu gewährleisten über Bord werfen

Von welchen Usern sprichst du denn hier? Die User haben doch gar nicht die Möglichkeit irgendwas über Board zu werfen. Ich fühle mich da jedenfalls nicht angesprochen. Ich hab das glaube ich ganz gut im Griff wann ich mich für einen Eingriff im Core entscheide "darf" und wann nicht.

ganz zu schweigen von solch von Unwissenheit geprägten Vorgehensweisen wie einfach eine Code-Stelle auszukommentieren. Nur nicht vorher fragen.

Manchmal treten Dinge plötzlich und unerwartet auf. Wie bei durch einen Newsletter bewusst herbeigeführten und durchaus gewünschtem hohen Traffic im Shop. Da wird man dann schon mal nervös wenn potentielle Käufer da sind, aber die Performance herunter geht. Da bleibt dann auch keine Zeit mehr vorher zu fragen. Genau dann erscheint mir das schnelle Auskommentieren durchaus die sinnvollere Vorgehensweise als sich zu überlegen... wie war das doch gleich... geht es vielleicht auch irgendwie eleganter?

Aber das mit dem "nullen" des Max-Wertes ist ein super Hinweis den ich natürlich gerne annehme, da es viel eleganter ist, als einen weiteren nicht-updatefähigen Eintrag in den core-Dateien drin zu haben. Und auch die log-Einträge will man ja nicht.

Ich wunder mich immer wieder mit welcher charmant-empathischen Leichtigkeit noRiddle diese kniffligen Modified-Fragen des Lebens zu beantworten weiß. Hut ab und nochmals vielen Dank - echt!

Bleibt noch die Frage: Was machen diejenigen Shopbetreiber, die viele Bestellungen haben und auf AlsoPurchased nicht verzichten können? Hier wärs doch vielleicht eine gute Idee die query auf die letzten X Monate zu begrenzen oderso. Nur so eine spontane Idee eines jungen Padawans.

[noRiddle (revilonetz)]

Zu benutzen AlsoPurchased ich für sinnvoll nicht erachte.

Meine Wenigkeit interessiert in einem Shop den ich besuche eines überhaupt nicht, nämlich was andere gekauft haben. Weiß gar nicht wer diesen Blödsinn überhaupt erfunden hat. Dasselbe gilt für Bestseller (auch ein Performance-Killer bei sehr vielen Bestellungen in der DB).
Als viel besser empfinde ich ein Modul welches bestimmte Artikel die man pushen möchte anzeigt und welche das sind sollte man selbst bestimmen können.
So etwas ist einfach zu bauen, indem man z.B. die Box Bestsellers kopiert, umbenennt (auch im Code selbstverständlich) und sie dann Artkel anzeigen lässt die man z.B. in eine bestimmte Kategorie verlinkt.
Heißt, man legt sich eine Kategorie an welche man jedoch nicht freischaltet und alle Artikel die man in diese Kategorie verlinkt hat werden dann als "Bestseller", die dann wohl besser "Unsere Empfehlungen" o.ä. heißen sollte angezeigt. Dafür benötigt man eine simple Query.
Okay, das wäre ein sinnvoller Ersatz für Bestseller, nicht für AlsoPurchased,. Letztgenanntes würde ich sowieso ganz rauswerfen. Besser CrossMarketing verwenden.

Gruß,
noRiddle

[demoncleaner]

Dem kann ich nur beipflichten. Bestseller hatte ich schon zuvor verbannt. Nicht aus Performance Gründen sondern weil es einfach nicht zwingend die Produkte sind, die ich überall angezeigt sehen möchte. Auch weil die Bestseller ja z.B. nicht immer zwangsläufig auch die lukrativsten Produkte sind. Um nur mal einen Grund zu nennen.

Heißt, man legt sich eine Kategorie an welche man jedoch nicht freischaltet und alle Artikel die man in diese Kategorie verlinkt hat werden dann als "Bestseller", die dann wohl besser "Unsere Empfehlungen" o.ä. heißen sollte angezeigt

Nette Idee. Ist ja ein bisschen so ähnlich vom Grundprinzip her wie das Modul Zusatzartikel unter Warenkorb https://www.modified-shop.org/forum/index.php?topic=24714.0

[online-beobachter]

Zu benutzen AlsoPurchased ich für sinnvoll nicht erachte.

Meine Wenigkeit interessiert in einem Shop den ich besuche eines überhaupt nicht, nämlich was andere gekauft haben. Weiß gar nicht wer diesen Blödsinn überhaupt erfunden hat....

Sorry - das kann ich nicht so stehen lassen.
Als Händler für Ersatzteile finde ich es sehr wohl Sinnvoll und das auch aus Kundensicht - zu sehen was ein andere Kunde zusammen gekauft hatte bzw. was wohl zusammen passt um sein Gerät zu reparieren.
Am besten noch dieses Ergebnis unten Sortiert nach Relevanz, also oft zusammen gekauft von verschiedenen Kunden.
Am liebsten würde ich auch eine höhere Anzahl anstatt einer kleinen anzeigen lassen, aber das ist schwer möglich ohne die Ladezeiten extrem zu verschlechtern?
Umso mehr Artikel in unterschiedlichesten Kategoriene fallen, je Sinnvoller ist dieses Feature.

[noRiddle (revilonetz)]

Für "was wohl zusammen passt" ist CrossMarketing da. Mich nervt diese AlsoPurchased, weil das nämlich den Parameter "passt zusammen" nicht zwingend berücksichtigt.
Ich kauf' mir 'n Zelt und 'ne Mütze im Outdoor-Shop.
Der nächste kauft 'n Zelt und sieht dann 'ne Mütze als "andere haben auch gekauft" Häää ?
Wozu soll das gut sein außer zur Verblödung ?

Gruß,
noRiddle

[online-beobachter]

Ich sag ja nicht das es für jeden Shop Sinnvoll ist, aber für manche schon.
CrossMarketing hat den Nachteil das man zwingend alles selbst einpflegen muß, was extrem mühsam und zeitaufwenig durch Rechergearbeit ist.
Bei AlsoPurchased geschieht das nebenbei ohne mein eigenes zutun, was schon mal ein Vorteil ist.
Warum sollte man so eine Funktion nicht nutzen wollen, wird ja einfach nur unten mit angezeigt - und wenn das Performanceproblem nicht so groß wäre könnte man das auch noch ausweiten.