Error 503 Service Unavailable - Shops sehr langsam nach Server Umzug bei Ionos.

[Hardstuff]

Hallo zusammen,

Wende mich an euch in der Hoffnung vielleicht eine Lösung für mein Problem zu finden.

Folgendes:

Habe 2 modified Shops auf einen Server von Ionos laufen. Tarif bei Ionos: Dedicated Server L-32 SSD managed

Shop A: Shopssoftware v2.0.2.1 rev 10607 dated: 2017-01-25
Url: https://tabassum.store

Shop B: Shopssoftware v2.0.5.0 rev 12487 dated: 2019-12-13
Url: https://doktorhardstuff.de

Problem: Beide Shops sind wie ausgebremst. Es häufen sich „503 Service Unavailable“ Fehler.

Die Shop suche liefert nur mühselig Ergebnisse. Such Vorschläge dauern auch sehr lange. Generell sind beide Shops sehr langsam. 503 Fehler sind sehr häufig obwohl Besucherzahl gering ist. Dies war vorher nicht so aber da liefen beide Shops auf verschiedenen Servern bei Ionos.

Kann mir jemand etwas dazu sagen an was das liegen könnte? Laut Ionos ist bei deren Server alles in Ordnung.

Das ganze erstreckt sich schon ca. 2 Wochen. Bin für jede Hilfe oder Lösungsansatz dankbar.

Grüße

Ahmed

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

[noRiddle (revilonetz)]

Wie hast du die DBs umgezogen ?
Falls mit mySQLDumper oder dem php-7.X-kompatiblen Nachfolger myOOSDumper, da passiert es oft, daß die Indices in den Tabellen deaktiviert sind. Solltest du mal prüfen.

Code: SQL  [Auswählen]

SHOW INDEXES FROM TABELLEN_NAME;

würde dir im Comment-Feld zeigen ob Keys disabled sind.
Um alle auf einmal zu prüfen müsste man das in ein Skript in einem Loop formulieren.

Wenn die Keys enabled sind könnten die Cardinalities nicht drin sein. Das könntest du mal als erstes ausprobieren, indem du in phpMyAdmin alle Tabellen markierst (kann man in der Regel in der Tabellenübersicht ganz unten mit einem Klick machen)  und für die markierten Tabellen ein "Analyze table..." laufen lässt.
Wenn's danach besser ist, gut.

Was, wenn man sehr viele Artikel hat die Startseite langsam machen kann, sind die Artikel auf der Startseite wenn man keine Artikel fest auf die Startseite verlinkt hat, dann werden nämlich welche "at random" aus der DB gesucht, was bei vielen Artikeln ziemlich lange dauern kann.

Dasselbe gilt für Neue Artikel auf, die auch erstmal mit Vergleich der Einstellungsdatums aus der DB geholt werden (je nach Einstellungen im Backend).

Ich vermute allerdings DB-Probleme mit disabled Keys und/oder fehlender Cardinality.

Gruß,
noRiddle

[Timm]

Was, wenn man sehr viele Artikel hat die Startseite langsam machen kann, sind die Artikel auf der Startseite wenn man keine Artikel fest auf die Startseite verlinkt hat, dann werden nämlich welche "at random" aus der DB gesucht, was bei vielen Artikeln ziemlich lange dauern kann.

Wie meinst du das? Wenn man keine Artikel auf der Starseite anzeigen lässt, weil man keine TOP Artikel markiert hat, dann werden dort doch auch keine angezeigt. Wird die Berechnung dennoch durchgeführt?

Dasselbe gilt für Neue Artikel auf, die auch erstmal mit Vergleich der Einstellungsdatums aus der DB geholt werden (je nach Einstellungen im Backend).

Wenn man diese aber auch nicht auf der Startseite oder über die Box anzeigen lässt, sondern als Menüpunkt im Kategoriebaum, kommt es auch nicht zu einer Verlangsamung, oder?

Gruß Timm

[noRiddle (revilonetz)]

Zu Frage 1.:
Es werden Artikel auf der Startseite angezeigt, auch wenn keine auf die Startseite verlinkt sind, abhängig von den Einstellungen im Backend bei
Konfiguration => Maximum Werte => "Neue Artikel Anzeigemodul" und ~ => "Anzahl der Tage für Neue Produkte"
Wenn erstgenannter Wert auf 0 steht wird nichts angezeigt und auch kein unnötiger Code ausgeführt.
Meinen Zusatz zum Thema "Neue Artikel", nämlich "(je nach Einstellungen im Backend)", hätte ich auch zu dem Thema Startseitenartikel schreiben müssen.

Zu Frage 2.:
Da habe ich micht genau genug ausgedrückt. Ich meine die neuen Artikel unter den (Haupt-/Ober-) Kategorien im Kategorielisting. Das ist aber bei Weitem nicht so langsam wie das Erwähnte für die Startseite. Es werden auch beide genannten Einstellungen beachtet aber es wird bei der Query nach products_date_added sortiert und darauf liegt ein Index. Der wirkt natürlich umso weniger je weniger unterschiedliche Daten in dem Feld stehen.
Will sagen: Hat man an ein und demselben Tag alle oder die meisten Produkte in den Shop geladen ist die sog. Cardinality des Index sehr niedrig und das DBMS wird den Index nicht verwenden.
(Cardinality zeigt an wieviele unterschiedliche Werte es in dem Feld mit dem betroffenen Index gibt, je höher desto besser, gemessen an der Menge der Einträge in der Tabelle, desto besser für die Schnellikeit und desto whrscheinlicher, daß das DBMS den index auch verwendet,)

Allerdings ist die Box für neue Artkel die du erwähnst bei sehr vielen Artikeln im Shop auch zeitraubend und resourcen-fressend und zwar nur bedingt abhängig von oben erwähnter Einstellung bei "Anzahl der Tage für Neue Produkte", weil der Code der einen random Artikel aus der DB holt für die Box immer ausgeführt wird und die genannte Einstellung lediglich eine Einschränkung des Pools aus welchem ausgewählt wird bewirkt.

Bei dem ganzen Reflektieren darüber was so im Hintergrund abgeht macht sich wieder stark bemerkbar wie unzulänglich und teilweise völlig unzutreffend die Beschreibungen bei den Einstellungen im Backend sind, leider.
Dem müsste sich mal jemand annehmen, vielleicht sogar die Autorin des modified-Buches..., wobei sie ja wahrscheinlich mehr das Interesse haben dürfte das Buch zu verkaufen... 

Gruß,
noRiddle

[Timm]

Danke für deine ausführliche Antwort.

zu Frage 1
hab ich auf 0 stehen. Das beruhigt mich. Es kam erst so rüber, als würde immer unnötig code ausgeführt werden.

zu Frage 2
Bei Punkt zwei hab ich mich nicht genau genug ausgedrückt. Es kommt durch den Menüpunkt neue Artikel im Kategoriebaum auch zu einer Verlangsamung, aber die fällt am geringsten aus. Weil dann nichts randomisiert werden muss, da alle Artikel angezeigt werden, die in einem bestimmten Zeitraum neu hinzugefügt wurden und nicht nur ein Teil davon (1 in der Box oder etwas mehr auf der Startseite). Man kann festhalten, dass die ressourcenschonendste Methode für das anzeigen der neuen Artikel die im Kategoriebaum ist, vor der Box auf der linken Seite und vor den neuen Artikel auf der Startseite.

Gruß Timm

[noRiddle (revilonetz)]

Das ist ganz gut zusammengefasst. Der Menupunkt "Neue Artikel" im Kategoriebaum, bzw. sein Aufruf, also, /products_new.php, dürfte allerdings eigtl. nicht so langsam sein weil es erstens einen Index auf products_date_added, wie gesagt, und zweitens das Paging gibt (...wobei ich noch nicht explizit geprüft habe ob der Index auch benutzt wird).
Richtig langsam wird's wirklich nur bei den random Artikeln auf der Startseite und sehr vielen Artikeln im Auswahl-Pool.
Das liegt an einem tricky ORDER BY, nämlich

Code: SQL  [Auswählen]

ORDER BY MD5(CONCAT(p.products_id, CURRENT_TIMESTAMP))

wo, um das ORDER BY überhaupt durchführen zu können auf jedes Produkt in der Tabelle products erstmal der Hash ausgerechnet werden muß. Dafür soll es besser (schneller und zufälliger) sein als normales ORDER BY RAND().

Gruß,
noRiddle