Neu Shop4 / MySQL 5.7 / Apache2

[maydo]

Danke für die Tipps --direct habe ich auf den platten aktiviert.

filesystem ist ext4, was das journaling eigentlich ausmacht, probiere es ohne das journaling auszuschalten. bzw. werde es noch auf einem testserver testen.

PS: als Ergänzung vor dem Ausschalten des Journaling muss das fs als read only gemountet werden-
-remount-ro flag für tune2fs

werde über die ergebnisse berichten.

 

[DITH-Shop]

Danke für die Tipps --direct habe ich auf den platten aktiviert.

filesystem ist ext4, was das journaling eigentlich ausmacht, probiere es ohne das journaling auszuschalten. bzw. werde es noch auf einem testserver testen.

PS: als Ergänzung vor dem Ausschalten des Journaling muss das fs als read only gemountet werden-
-remount-ro flag für tune2fs

Ja, das ist korrekt. Ich wollte das hier aber eigentlich NICHT öffentlich bekannt geben da das die letzte Sicherheit (Hürde) für diejenigen ist, die keine Ahnung haben was sie tun und ohne nachzufragen einfach machen was irgendwo geschrieben steht.

 

[DITH-Shop]

Wenn man ds System dann stabil laufed hat, kann man zur weiterer Geschwindigkeitssteigerung die Server-Protokolle ebenfalls ausschalten. Das bringt noch mal nen Schub.

Schaut man sich ein komplett neu aufgesetztes System mit "iotop" an, wird man feststellen, das nahezu 99% der Festplattenauslastung von Journal, Protokoll, Logging und so nem Mist ausmacht.

 

[maydo]

Schaut man sich ein komplett neu aufgesetztes System mit "iotop" an, wird man feststellen, das nahezu 99% der Festplattenauslastung von Journal, Protokoll, Logging und so nem Mist ausmacht.

das ist korrekt.
als info > bei einem neu aufgesetzten server spielt der ulimit (anzahl max geöffneter dateien) noch ne rolle, der ist standardmässig auf 1024 eingestellt und sollte unbedingt erhöht werden.

bin im moment bei 3,5Artikel/sec, was etwas besser ist als beim alten server, aber immer noch nicht befriedigend.
ausser dem journal habe ich alles andere optimiert. was ne verdopplung herbeigeführt hat.

läuft bei dir ein software raid ?

hilfreiche links
https://www.percona.com/blog/2014/05/23/improve-innodb-performance-write-bound-loads/

PS: Der Bilderabgleich gleicht 50k Bilder unter einer Stunde ab. Ein halb so schneller Artikelabgleich wäre ein Traum

 

[DITH-Shop]

läuft bei dir ein software raid ?

Ja

 

[maydo]

shopseitig ist soweit alles optimiert

ein im shop angekommendes 400er paket, liest der shop in 35sec ein. was in etwa 11,5 art./sec entspricht.

der neue flaschenhals ist wawiseitig, das packen des workers dauert auch noch zu lange, hier muss ich noch optmieren.
@DITH-Shop
weißt du wo der worker die zu sendenden pakete abspeichert ?

wenn ich die gesamtzeit incl. packen des workers + abarbeitung im shop berechne, lande ich bei etwa 3art/sec

 

[maydo]

Ich lasse Pakete zu 600 Artikel von der Wawi erzeugen und an den Shop zum Abgleich senden.
Das zusammenpacken dauert ~2-3 Sekunden, das übertragen <1Sek..

wie hast du das festgestellt ?
bei mir dauert das zusammenpacken ewig im vergleich.

siehe screenshot, sind alles 500er pakete die ca. alle 4min im shop ankommen, das abarbeiten im shop dauert keine 30sec.
der flaschenhals ist der worker.

 

[DITH-Shop]

@DITH-Shop
weißt du wo der worker die zu sendenden pakete abspeichert ?

IMHO werden die gar nicht gespeichert sondern im RAM gepackt.

Wenn der Worker nun das Problem ist, dann VERSUCHE bitte mal folgende Einstellung zu ändern:
(Bei MIR hats geholfen, auch wenn es laut Support so NICHT sein sollte)

DB-Eazybusiness - Eigenschaften - "Optionen" - "Sonstiges" => "Parametrisierung" auf "Erwzungen" umstellen

 

[DITH-Shop]

wie hast du das festgestellt ?
bei mir dauert das zusammenpacken ewig im vergleich.

siehe screenshot, sind alles 500er pakete die ca. alle 4min im shop ankommen, das abarbeiten im shop dauert keine 30sec.
der flaschenhals ist der worker.

Bei mir sind es auch ~4 Minuten - aber für 1500er Pakete

 

[maydo]

sind bei dir ca 6,5 art/sec, damit wäre ich mehr als zufrieden

so sieht das bei mir mit1500er paketen im moment aus.
wobei der worker zu lange braucht.

DB-Eazybusiness - Eigenschaften - "Optionen" - "Sonstiges" => "Parametrisierung" auf "Erwzungen" umstellen
das habe ich eingestellt, mal sehen was es bringt

 

[maydo]

"Parametrisierung" auf "Erwzungen" umstellen
das wars hat locker 5min pro paket rausgeholt

bin im moment bei 8min für 2000er pakete was in etwa 4art/sec im gesamtabgleich ausmacht.
damit kann ich leben.

danke für die Tips,

 

[maydo]

habe noch den Shopcache von redis zu advancedfile bzw. file umgestellt, was den shop selbst auch schneller gemacht und den serverload etwas entlastet hat(@jtl was ist der unterschied ?)

das bringt nochmal was.
siehe screenshot

damit gleichen wir nun 50k artikel unter einer stunde ab.
~25Artikel/sec

 

[css-umsetzung]

Das keine gute Idee.
Der cache über die Files ist in beiden Varianten extrem felheranfällig. Bei einigen Kunden wo kein Redis möglich ist musste ich den cache deswegen komplett deaktivieren.

 

[maydo]

habe die lifetime sicherheitshalber auf 60s runtergeschraubt.
was ist der unterschied zwischen advancedfile und file ?

 

[css-umsetzung]

Beim zweiten werden die Files in verzeichnissen verteilt, das wird gemacht, weil in der ersten Variante in einem Verzeichnis zu viele Files landeten die dann nicht mehr gelöscht werden konnten.

Leider entstehen in der zweiten Variante je nach Lust und Laune, symbolische Links, die vom shop nicht mehr gelöscht werden können, was dann zum Totalausfall führen kann (nicht muss) . Diese Probleme gibt es auch noch im 4.6er Shop.

 

[maydo]

danke für die info, das kann man ja rel. einfach überwachen, da ist die erste var. immer noch sicherer.

 

[ag-websolutions.de]

Sofern redis genutz werden kann, sollte man immer von dieser cache-Variante gebrauch machen

 

[css-umsetzung]

Der Redis cache sollte eigentlich immer die schnellste Variante sein, komisch das dies bei dir nicht so ist.

 

[maydo]

Sofern redis genutz werden kann, sollte man immer von dieser cache-Variante gebrauch machen

der shopabgleich ist mir wichtiger, der mit filecache um fast faktor 10 schneller läuft.
der shop selbst ist ebenfalls etwas schneller (laut webpagetest.org), was mir eigentlich egal ist, gefühlt merke ich da kein unterschied zu redis, filecache oder deaktiviertem cache.

 

[maydo]

update: der filecache ist in der tat eine katastrophe
man kann ihn zwar etwas bändigen indem man den cacheordner alle paar minuten über einen cronjob leert.

trotzallem, bin wieder auf redis, und konnte redis auch soweit optimieren, dass der abgleich auch mit redis sehr flott läuft
- abgleich filecache 25 files/sec
- abgleich redis 18-20 files/sec

das ist mehr als erwartet und ausreichend.