Neu Speed Abgleich Shop 4

[maydo]

Hi,

unser Shop 4 arbeitet 2000 Artikel in 20 Minuten ab (Vollabgleich, kein Quicksync). d.h. es sind ca. 1,6 Artikel per Sekunde.
Das ist zu langsam.

Der Server ist ein root, es läuft nur der Shop drauf.

32 GB Ram
Intel i5-4590 Quad-Core
SSDs im Raid1 Verbund.

Der trödelt nur vor sich hin.
mysql an sich ist bereits optimiert.
Die Tabellen sind alle nach "initial_schema.sql" eingerichtet. (InnoDB & MyISAM)

Worker läuft mit 2000 Artikel und 5MB Filegrösse (die 5MB werden aber nicht erreicht, ca 2MB sind es im Schnitt)
Wird direkt vom lokalen Server gesendet, der wartet dann 20 Minuten für das nächste Paket, bis der Shop die Rückmeldung gibt.

An welcher Schraube kann hier noch optimiert werden ?
Wie sind eure Erfahrungswerte ?

 

[DITH-Shop]

Oh, Ja - BITTE @JTL

Es muss doch jemanden bei euch geben der für den Shop und interne Abläufe zuständig ist, und daher genau wissen muss, wo geschraubt werden kann.
Auch bei mir tröpfelt es mit 1-2 Updates/sek. herum. CPU Last aber gerade einmal 20-30% - MySQL langweilt sich dabei zu Tode
Bei knapp 300.000 Artikel die täglich geupdatet werden müssen ist das untragbar.

HP ProLiant, 32GB, 2x XEON 3,3GHz, RAID1 160GB SSD
Nur DB + Shop4 auf Apache2, PHP7-FPM

 

[david]

Auch bei mir tröpfelt es mit 1-2 Updates/sek. herum. CPU Last aber gerade einmal 20-30% - MySQL langweilt sich dabei zu Tode

Wenn sich dein Webserver beim Abgleich langweilt, dann ist offenbar nicht der Shop der Flaschenhals.
Wie schaut es denn mit der Auslastung des Wawi-Rechners, insbesondere der MS-SQL aus?

 

[DITH-Shop]

Wenn sich dein Webserver beim Abgleich langweilt, dann ist offenbar nicht der Shop der Flaschenhals.
Wie schaut es denn mit der Auslastung des Wawi-Rechners, insbesondere der MS-SQL aus?

Ich glaube ja kaum das der MS SQL was damit zu tun hat
Die Wawi gibt Pakete zu 400 Artikel an den Shop (erstellt in 2-3 Sekunden, übermittelt per lokalem GB Netzwerk in einer Sekunde), der bearbeitet dann aber nur 1-2 Artikel je Sekunde.
Offensichtlich nur FiFO (seriell) und NICHT mit 10-20 parallelen Threads wie es die meisten anderen Tools (bspw. Unicorn2) machen würden.
Maximale MySQL Auslastung hatte ich gerade bei 43% - DER ist also nicht das Problem.
FPM darf bei mir mit 20 parallelen Tasks arbeiten, aufgerufen werden in der Regel so um die 4-5, da hängts also auch nicht.

Der Apache sollte eigentlich auch nicht das Problem sein?!

ServerLimit 16
StartServers 3
ThreadLimit 64
MaxClients 400
MinSpareThreads 30
MaxSpareThreads 90
ThreadsPerChild 25

(Sollte da ggf doch noch geschraubt werden?)

ODER habe ich beim Shop eine Einstellung übersehen?

 

[maydo]

Der Worker müsste mehr Kerne nutzen können, aktuell wird nur einer genutzt.
Dabei verliert der Worker vielzuviel Zeit beim Packen der Artikel, die Übetragung zum Shop und das Einlesen im Shop ist nicht der flaschenhals.
Eher der Worker > max. 1 Kern.
Hier sollte unbedingt eine Veränderung stattfinden

 

[FMoche]

Nutzt du denn einen ordentlichen MSSQL-Server? Die Express-Version unterstützt doch meines Wissens nach nur einen Core.

 

[DITH-Shop]

Nutzt du denn einen ordentlichen MSSQL-Server? Die Express-Version unterstützt doch meines Wissens nach nur einen Core.

Bitte erst genau lesen was geschrieben wurde, dann erst antworten. Es geht ihm um den WORKER und NICHT um den SQL Server.
Wenn der WORKER nur auf einem Kern arbeitet, ist es nicht relevant wie viele Kerne der SQL Server nutzt.

 

[FMoche]

Meine Antwort war nicht allein auf den letzten Kommentar von maydo bezogen, sondern auf das Gesamtthema.
Und dann spielt das durchaus eine Rolle. Wenn ich einen Komplettabgleich ohne Worker mache, habe ich nämlich genau das Problem.

 

[elevennerds.de]

Hallo,

fast immer ist bei Datenbanken die IO-Bandbreite der Flaschenhals, daher bitte mal während des Abgleichs auf dem Shop-Server ein "iotop" laufen lassen.

MfG

Rene

 

[DITH-Shop]

Hallo,

fast immer ist bei Datenbanken die IO-Bandbreite der Flaschenhals, daher bitte mal während des Abgleichs auf dem Shop-Server ein "iotop" laufen lassen.

MfG

Rene

iotop war nen guter Hinweis.
Da war an ein paar Stellen noch das Logging / Errorlog aktiviert.
Durch deaktivieren derselben konnte ich die MySQL CPU-Last um knapp ~10% anheben. Was jetzt aber leider auch nicht soooo der Bringer war.

Vorher waren es 1,6 Artikel/Sek. Jetzt sind es 1,7

 

[maydo]

Nutzt du denn einen ordentlichen MSSQL-Server? Die Express-Version unterstützt doch meines Wissens nach nur einen Core.

ist sql 2014 standard was bis zu 24 kerne unterstützt.
der sql ist nicht der flaschenhals, sondern der worker als prozess, dieser nutzt nur einen kern beim zusammenstellen (zippen) des paketes
z.b. 800 artikel, das zusammenstellen dauert ca. eine minute (gefühlt), das senden an shop > shopverarbeitung > rückmeldung keine 10 sekunden > dann wieder paket zippen worker < und genau hier ist der flaschenhals, die ressourcen (wenn vorhanden) mehrere kerne, sollte der worker auch nutzen.

 

[DITH-Shop]

das senden an shop > shopverarbeitung > rückmeldung keine 10 sekunden

Kannst Du mir bitte die Config des MySQL und des Apache mitteilen?
800 Artikel dauern bei mir knapp 9 Minuten.
Oder meinst Du QuickSync?

 

[maydo]

nein kein quicksync, der normale abgleich, bei uns ist das zippen des workers der flaschenhals, der shop kommt super damit klar.

kann ich dir morgen posten, heute abend komme ich an die daten nicht mehr dran.
den webserver haben wir allerdings auch monatelang optimiert, verschiedene raids. etc.
raid 1 ssd, raid 10 ssd, raid 5 ssd.
raid 5 ssd (mdadm) war die beste speedlösung

 

[DITH-Shop]

Also, zu Shop 4.05 habe ich jetzt ein Problem identifizieren können.

ICH habe zu meinen Artikeln (hauptsächlich DVD / BR Filme) insgesamt (!) laut tArtikelmerkmal über 456000 Einträge für Merkmale (insbesondere sind das Darsteller, Regisseure und für AudioCD auch Interpreten)

Da es JTL augenscheinlich vorzieht statt eines ggf vereinzelt notwendigen Updates bei Änderung, grundsätzlich immer erst die Merkmale eines Artikels zählt, dann alle Merkmale des Artikels löscht um sie anschließend alle erneut anzulegen (das geht zumindest aus dem Quellcode Artikel_xml.php und Merkmal_xml.php sowie den Abläufen im Server hervor) - zieht das den Server bei mir enorm herunter.
Statt eines knappen Updates des Artikels (ein einmal angelegter Artikel ändert sich bei mir nur äußerst selten), werden dann bei MIR mal so eben locker 60-100 SELECT, DELETE und INSERT durchgeführt

Dass DAS enorm aufhält ist selbstredend.

Mal schauen ob ich das nur abschalten oder komplett umbauen muss.

 

[DITH-Shop]

Wie ich gerade leider feststellen musste, gilt dasselbe für tPreis, tPreise, tPreisdetail und tPreisverlauf.
Auch hier statt Update immer erst DELETE und INSERT (sogar für Artikel die sich seit Tagen nicht geändert haben)

 

[Thomas Lisson]

hi,

die Wawi speichert nciht zu jedem Objekt, was sich daran geändert hat - dann könnte man einfach Updaten.
Wenn du nicht vorher alles löschst, wirst du gelöschte Preise, Merkmale etc. nie mehr aus dem Shop bekommen...

 

[DITH-Shop]

Es gibt in MS SQL als auch in MYSQL die Möglichkeit ein "Update xxx where yyy" durchzuführen.

Beispiel: "Update tartikelmerkmal set Merkmalwert = <NeuerWert> where Merkmalwert <> <NeuerWert>"

Das optimiert viele Sachen gleichzeitig. Zuerst wird nur dann etwas geupdatet was sich geändert hat, und es fallen viele DELETE und INSERT weg.
Speziell in meinem Fall wären das je nach Artikel zwischen 10 und 100 Merkmale.

Preis dasselbe: "Update tPreis set cValue = <NeuerPreis> where <NeuerPreis> <> cValue"

Unnötige Merkmale, Attribute und Preise aus der DB löschen geht per simpler Funktion (ggf 1x täglich) genau so einfach.
Delete from tPreis where kartikel not exist(select kartikel from tartikel)
vice versa

(Alle SQLs frei aus dem Kopf, ungeachtet ob die Tabellennamen und/oder Spaltennamen korrekt sind)


Ich stamme aus einer Zeit wo Computer mit 32KB RAM und wenigen kHz klar kommen mussten, daher wurde in meiner Zeit extrem Wert auf Performance gelegt.
Eine Verschwendung von Ressourcen ist ein absolutes NoGo.

Um bei meinem speziellen Fall von etwas größeren Mengen an Merkmalen zu bleiben.
Meine DB muss im Tagesdurchschnitt 1,2 Mio SQL abarbeiten. Aus meiner Sicht wären davon die Hälfte überflüssig wenn die SQL etwas anders aufgebaut würden. (Mehr Views, bessere Indize, genauere Einschränkungen)


Wie gesagt - es scheint insbesondere bei mir an diesen Stellen zu klemmen, bei ANDEREN scheinen DIESE Probleme nicht so ins Gewicht zu fallen, daher werde ICH für MICH diese Probleme selbst beheben bis ggf mal seitens JTL,bei ausreichend freier Kapazität, wieder an der Optimierung gearbeitet wird.

 

[Thomas Lisson]

Hi,

Beispiel: "Update tartikelmerkmal set Merkmalwert = <NeuerWert> where Merkmalwert <> <NeuerWert>"

Das reicht nicht - wir kennen den Zustand der Objekte nicht. Wir wissen nicht, was sich verändert hat. Muss was hinzugefügt werden, muss ein Wert aktualisiert werden oder muss ein Wert gelöscht werden.

Du kannst es ruhig für dich umbauen, wie du es brauchst - wir können hier nicht optimieren. Wir müssen alle Anwendungsfälle erschlagen, insbeosndere ein Datenbankrestore in der Wawi darf und den Shop nicht aus dem Tritt bringen.

 

[DITH-Shop]

Helau !

Problem bei MIR gelöst.

• Update auf Shop 4.05.1
• aus der Synchro den Preisverlauf auskommentiert da ich das nicht benötige
• an der MySQL Konfig eine kleine Stellschraube gefunden und "gedreht" -
  Wer es vielleicht auch versuchen möchte: "innodb_flush_log_at_trx_commit" von "0" auf "2" gesetzt UND "innodb_flush_log_at_timeout" hinzugefügt mit dem Wert "2"

Ergebnis (vollständiges Update, nicht Quicksync)
VOR den Änderungen: 1 Paket mit 800 Artikel dauerte 17 Minuten
NACH den Änderungen: dieselbe Paketgröße in 58 Sekunden - WOW !!!! Damit kann ich gut arbeiten