Wir haben seit dem Update auf 5.2.22 erhebliche Performance Probleme - Ausgangpunkt war die 5.1.2 Version.
Unsere Serverantwortzeit ist von ca. 1-1.1 auf 1.6-17s gestiegen - sieht nach internen Bottlenecks im System aus. Hat jemand ähnliche Erfahrungen gemacht?
Hallo,
das Shopware-Core Systeme verursacht im Vergleich zu vorherigen Versionen keine Steiegrung der TTFB-Werte in diesen Dimensionen. Gilt auch für Premium-Plugins, die ich bei Kunden im Einsatz habe. Sind die Werte im Bearbeitungsmodus im Frontend aufgetreten?
Grundsätzlich müsste bei der Frage nach der Performance das Shopsetting (z. B. Artikelanzahl, Bearbeitungsmodus) und das Serversetting wenigstens grob angegeben werden.
Kein Bearbeitungsmodus
HTTP CACHE (APCU und OPCache) an
+50.000 Artikel
6 Subshops
3 Server a’:
22 Cores (Intel Xenon 3 Ghz)
16 GB RAM
150GB HDD
1 DB Server:
4 Cores (Intel Xenon 3 Ghz)
Fusion I/O SSD
32GB RAM
Alle 3 Appserver greifen auf den DB Server zu - Cache haben die Server einen getrennten jeweils im home Verzeichniss von Shopware. Media Daten liegen auf einem NFS.
Stehen die Kisten im gleichen RZ ? Falls nicht, könnte Latency auf der Strecke (gerade wenn Du Verzeichnisse per NFS einhängst) ein Thema sein …
VG
Hi Misengo,
reden wir jetzt eigentlich über den TTFB-Wert, den die index-Seite des Controllers erzeugt, solange diese sich nicht im HTTP-Proxy befindet oder über die Gesamtladezeit der Seite inkl. aller Bilder/Assets? Der erste Schritt wäre doch zu schauen, wer die Ladezeiterhöhung verursacht, die App-Server, der DB-Server die NFS-Shares, der HTTP-Proxy auf dem App-Server?
Nehmt ihr den Standard HTTP-Proxy von Shopware? Warum liegt der überhaupt auf einer HDD, wenn ihr schon auf App-Server verteilt?
Stehen die Kisten im gleichen RZ ? Falls nicht, könnte Latency auf der Strecke (gerade wenn Du Verzeichnisse per NFS einhängst) ein Thema sein …
VG
Ja die befinden sich alle im gleichen RZ.
Die TTFB ist mit 600ms ganz i.O. und ja wir nutzen den HTTP Proxy/Cache von Shopware. Unser Hoster hat uns empfohlen keine SSDs auf den Appservern zu nutzen, da kein Mehrwert (wenig I/O - da vieles davon im RAM ist).
Wir würden ja gerne wissen was die hohen Ladezeiten hervorruft, nur unser Hoster gibt uns da kein Feedback und ist keine Hilfe. Ich habe das System gerade mal auf meinem Ubuntu 16.04 Rechner (I7 Quad - 16GB - Intel SSD) laufen lassen, dort ist der Shop im Bearbeitungsmodus relativ schnell, verglichen mit unserem Stagesystem (ähnliche Specs wir mein Rechner).
Habe mal versucht dort XHProf zum laufen zu kriegen, ist aber nicht so einfach wie ich dachte, leider. Und Blackfire.io funktioniert leider nicht mit Ioncube -.-
Im ersten Post hast Du von einer Ladezeit von 1.1-17 Sekunden nach dem Update gesprochen. Damit ist aber 1.1 - 1.7 s gemeint, oder?
Der HTTp-Proxy von Shopware ist bei vielen Dateien im Cache schon mal langsamer. Das kann sich im Bereich von einem Faktor 2-4 bewegen. Aber damit kann man nur ~200ms im TTFB der “index.html” erklären.
Du kannst doch auch im Network-Panel deines Browers erkennen, an welcher Stelle Du höhere Ladezeiten hast - den Bildern (NFS-Share) oder dem App-Server.
Was ich bei fehlenden Monitoring-Tools schon mal mache, ist die einzelnen Server mit Top als Root zu verfolgen, wenn die Performance hakt. Evtl. siehst dort wo es hakt. Gerade wenn es an der Storag-Anbindung liegt, siehst Du dies evtl. am CPU Status.
Du bist nicht vollkommen auf Gedeih und Verderb der Kooperation deines Hoster ausgeliefert.
Ich verstehe ja nicht ganz, warum auf dem App-Server keine Dateizugriffe vorhanden sein sollen, die von einer SSD profitieren. Habt ihr var/cache/ komplett in einer RAM-Disk liegen?
Im ersten Post hast Du von einer Ladezeit von 1.1-17 Sekunden nach dem Update gesprochen. Damit ist aber 1.1 - 1.7 s gemeint, oder?
Der HTTp-Proxy von Shopware ist bei vielen Dateien im Cache schon mal langsamer. Das kann sich im Bereich von einem Faktor 2-4 bewegen. Aber damit kann man nur ~200ms im TTFB der „index.html“ erklären.
Du kannst doch auch im Network-Panel deines Browers erkennen, an welcher Stelle Du höhere Ladezeiten hast - den Bildern (NFS-Share) oder dem App-Server.
Was ich bei fehlenden Monitoring-Tools schon mal mache, ist die einzelnen Server mit Top als Root zu verfolgen, wenn die Performance hakt. Evtl. siehst dort wo es hakt. Gerade wenn es an der Storag-Anbindung liegt, siehst Du dies evtl. am CPU Status.
Du bist nicht vollkommen auf Gedeih und Verderb der Kooperation deines Hoster ausgeliefert.
Ich verstehe ja nicht ganz, warum auf dem App-Server keine Dateizugriffe vorhanden sein sollen, die von einer SSD profitieren. Habt ihr var/cache/ komplett in einer RAM-Disk liegen?
Wir haben Zabbix als Monitoring Tool und können so gut wie alle Werte auslesen (siehe Bild)
Das ist unser RAM verhalten, ich denke da wird wirklich fast alles aus dem RAM geladen. Um 01:00 Uhr kicken wir den Cache dann raus:
Ich würde Dir empfehlen, einmal Tideways einzusetzen, um den Flaschenhals zu finden: https://tideways.io/
Damit kannst Du PHP- und SQL-Prodiling betreiben.
Sind die Server denn auch über ein lokales Netz verbunden (für geringe Latenz), oder geht alles RZ-intern über das öffentliche Netz?
Timme Hosting - schnelles nginx-Hosting
@TimmeHosting haben wir schon gemacht. Das Cache schreiben braucht hier bei wenigen Requests 5000ms + was ungewöhnlich lang ist. Außerdem werden zum Beispiel auf der Startseite laut Tideways Topseller Controller geladen, obwohl dort def. keine Topseller geladen werden. Sehr komisch… In manchen Startseitencalls ist das zum Beispiel laut Tideways auch gar nicht drin.
https://picload.org/image/ridiiari/bildschirmfoto_2017-05-23_um_1.jpg
Hallo @Misengo
kannst Du nicht mal eine URL posten?
Bei dem geposteten RAM-Verlauf, würde ich darauf tippen, dass RAM solange alloziert wird, bis die 12 GB RAM bzw. das 95% Limit erreicht ist. Dann würde der der HTTP-Proxy von der Platte gelesen und das ist auf jeden Fall mit SSD schneller, bei SAS-Platten wäre der Unterschied wahrscheinlich nicht so groß. Hängt etwas von den Zugriffen ab.
Habt ihr eigentlich die Life-Time des Shopware HTTP-Proxies im Original belassen?
@hth habe die URL via PM gesendet. Interessant ist auch unsere InnoDB Buffer verhalten - wir hatten am 03.05.17 das Update auf Shopware 5.2.22 - die folgenden Abstürze kamen jeweils nach kompilieren und Cache leeren (24.05.2017)
Die Lifetime etc. ist alles auf dem Standard.
https://picload.org/image/riorgooi/bildschirmfoto2017-05-29um14.2.png
Der Fehler lag beim Hoster, der Query Cache wurde nach dem Update kurz ausgeschaltet und dann scheinbar zu niedrig wieder angesetzt… Das ganze hat nun mehrere tausend Euro und viel Nerven gekostet - diesen Hoster kann ich wirklich keinem weiterempfehlen, werde hier jetzt aber keine Namen nennen. So viel zu “Premium”…
Danke an alle für das Feedback!
Das ist sehr ärgerlich! Zum Glück habt ihr den Fehler gefunden. Um welchen Hoster handelt es sich (PN vielleicht)? Wir sind gerade auf der Suche nach einem neuen…
