Shopware Update - Performance Unterschiede

Hallo zusammen,

wir haben ein merkwürdiges Verhalten beim Update von Shopware auf einem unserer Server. Merkwürdig ist die benötigte Zeit zur durchführung un die hohe Last auf der Festplatte. Da wir das schon länger beochbachten habe ich nun mal das Update von V5.2.14 auf V.5.2.15 im Vergleich mit unserern anderen Servern dokumentiert und hoffe Ihr könnt mir einen Ansatz liefern, wo die Fehler-Quelle zu suchen ist. Getestet wurde ein Shop mit 40 Artikeln.

1&1 Unlimited - 40 CPU – 252 GB RAM – (unlimited) GB HDD (Shared Hosting)

Das Update per AutoUpdate dauert 2 Minuten

Das Update_per_Browser dauert 2 Minuten

Das Update per Konsole dauert 1,5 Minuten

Hostnet - Cloud Instanz - 4 CPU – 6 GB RAM – 200 GB SSD

Das Update per AutoUpdate dauert < 2 Minuten

Das Update_per_Browser dauert < 2 Minuten

Das Update per Konsole dauert 1,5 Minuten

PlusServer - Managed Root Server | 4 CPU | 32GB RAM | 500GB HDD

Das Update per AutoUpdate dauert geschlagene 15 Minuten , dabei verbringt der Updater 90% der Zeit mit der Datenbankmigration. Zusätzlich ändert das Update über das Backend die File Permissions von 644 auf 666 von jedem File der im Update Paket enthalten ist?? Aufgefallen ist das durch unseren Cron, der die Ausführung nach Update verweigerte weil die Datei (bin/console) durch diese Änderungen durch jeden Benutzer des Servers änderbar ist.

Das Update_per_Browser dauert ebenfalls 15 Minuten , dabei verbringt der Updater 90% der Zeit mit der Datenbankmigration. Hier lässt der Update die File Permissions aber so wie sie waren

Das Update per Konsole dauert ebenfalls 15 Minuten , dabei verbringt der Updater 90% der Zeit mit dem Import der Snippets. Auch hier lässt der Update die File Permissions so wie sie waren

Alle 3 Varianten des Updates haben auf diesem Server gemeinsam dass die Platte ordenlich Last hat. Laut Support vom Hoster ist diese aber ok. atop zeigt während der Datenbankmigration für sda 100% Auslastung und ist knalle rot. Aber sobald der Updater aufräumt (Cache leeren / Files löschen) ist die Platte wieder im normalen Bereich.

Hat jemand eine Idee, wo ich beim Hoster ansetzen kann?

Viele Grüße
RobKot

 

Dann muss es irgendwo an deiner Server Konfiguration liegen.

Selbst auf einen DigitalOcean Server mit 512MB RAM und 1CPU dauert das Auto Update nicht mehr als 1 Minute.

Dafür brauchst du keine brachiale Leistung …

@Shopwareianer schrieb:

Dann muss es irgendwo an deiner Server Konfiguration liegen.

Selbst auf einen DigitalOcean Server mit 512MB RAM und 1CPU dauert das Auto Update nicht mehr als 1 Minute

Hallo Shopwareianer danke für die schnelle Antwort. Wir stehen schon seit Monaten im Kontakt mit dem Hoster, haben die Netzwerkanbindung erweitert, RAM erweitert wir stehen kurz davor auf SSD umzustellen. Aber ich glaube nicht mehr daran dass das was bringt. Ich fragte ja auch nach einem Ansatz mit dem ich auf den Hoster zugehen kann. Ich vermute ein Problem mit MySQL in Verbindung mit der Platte.

Das kann man so nicht sagen, da es wirklich hunderte Faktoren geben kann. Mehr RAM wird da wohl relativ wenig bringen. Der Hoster selbst müsste da schauen woran es liegt. Denn 15 Minuten ist definitiv viel zu lange. Da macht es jetzt auch keinen großen Unterschied ob es eine HDD oder SSD .

Wenn du aber sagst, dass es bei der DB Migration so lange hängt, dann wird es sehr warscheinlich natürlich irgendwo mit dem MySQL Server zusammen hängen.

Handelt es sich bei dem Managed Server wirklich um eine dedizierte Maschine, oder ist es im Endeffekt nur eine virtuelle Maschine, die sich die Ressourcen des Hostsystems mit anderen virtuellen Maschinen teilt? Viele Hoster überbuchen die Hostsysteme, so daß es oft zu solchen Performanceengpässen kommen kann.

Ich würde auch einmal die Festplatten prüfen lassen, denn evtl. gibt es dort ein Problem, so daß es zu sehr hohen IO-Wait-Zeiten kommen kann (worunter dann besonders die Datenbank leidet).

Timme Hosting - schnelles nginx-Hosting

www.timmehosting.de