Hallo,
ich habe ein Geschwindigkeitsproblem bei Shopware 5.2.27(Frontend). Nach einer Analyse habe ich gesehen, dass das Sessionhandling ewig braucht (knapp 93%). Die Datenbank habe ich überprüft, Abfragen laufen in normaler Geschwindigkeit. Ich habe nur gerade keine Idee wie ich das beheben kann.
Erzähle mal was zum Shop: Anzahl Artikel/Varianten. Was für ein Server (RAM, CPU, SSD?). Upgrade auf Shopware 5.3 bald möglich? Verwendete Plugins?
Hatten wir auch. Sessions sollten ab gewisser Shop Größe / Benutzer aus der MySQL DB rausgenommen werden und über Redis oder Memcached gelöst werden. Funktioniert bei uns wunderbar, wobei Memcached Probleme mit den Sessions im Backend hat. Shopware Issuetracker
Hi,
Artikel:25 Kategorien:56
Artikelder Server liegt bei einem externen Hoster. Ich bezweifle stark, dass es an der Leistung des Servers hängt. Zudem war das Problem nicht schon immer da (Leider kann kein genauer Zeitpunkt angegeben werden). Querys die ich an die Datenbank schicke laufen in guter Zeit durch. Laut dem log macht nur der Zugriff und die Verarbeitung der Sessions Probleme. Und an Plugins habe ich nur welche aus dem Shop, keine eigenen und alle sind auf der neuen Version. (Soll ich alle auflisten?)
Schau’ mal ins Error-Log der website oder in die Shopware-Logs, ob Dir dort Probleme auffallen. Ansonsten kann es wie gesagt helfen, die Sessions nach memcache oder Redis auszulagern: Shopware Session handling
Timme Hosting - schnelles nginx-Hosting
Wie gesagt, war bei uns identisch. Die MySQL DB hatte nur mit den Sessions Probleme. Alles andere lief immer sauber und ultraschnell durch. Warum die Session Tabelle Ärger macht, konnte mir bis jetzt keiner sagen. Nach Verlagerung der Sessions zu memcached (in unserem Fall), ist das Problem erledigt.
Wo bekommst du die 93% Dauer fürs Session Handling angezeigt?
Kannst du mal einzelne Querys mitschneiden, damit man ein paar langsame Identifizieren und Testen kann?
Bei so wenig Artikeln in so wenig Kategorien (Anzahl der Kategorien, jedenfalls für die geringe Anzahl an Artikeln find ich jedoch etwas hoch) sollte es kein Problem sein.
Hoffentlich schaut sich das Shopware mal an.
Kannst du genau sagen wo im Shop es langsam ist? In den Warenkorb gehen, Artikel aufrufen, Varianten wählen, beim Einloggen oder Registrierung usw.?
# Time range: 2017-12-12 16:05:49 to 16:10:46
# Attribute total min max avg 95% stddev median
# ============ ======= ======= ======= ======= ======= ======= =======
# Exec time 27s 1us 7s 4ms 424us 117ms 28us
# Lock time 25s 0 7s 3ms 66us 117ms 0
# Rows sent 7.61k 0 316 1.01 0.99 13.06 0
# Rows examine 75.91k 0 7.84k 10.11 2.90 210.80 0
# Query size 3.74M 6 8.92k 510.68 2.06k 1011.81 174.84
# Profile
# Rank Query ID Response time Calls R/Call V/M Item
# ==== ================== ============= ===== ====== ===== ===============
# 1 0xB4B7C07F6C4915DA 24.7271 91.4% 74 0.3342 3.93 SELECT s_core_sessions
# 2 0x813031B8BBC3B329 0.6476 2.4% 79 0.0082 0.04 COMMIT
# 3 0x3BD6617E8476AB44 0.4440 1.6% 38 0.0117 0.01 UPDATE s_statistics_visitors
# MISC 0xMISC 1.2440 4.6% 7498 0.0002 0.0 <167 ITEMS>
# Query 1: 0.25 QPS, 0.08x concurrency, ID 0xB4B7C07F6C4915DA at byte 1662028
# This item is included in the report because it matches --limit.
# Scores: V/M = 3.93
# Time range: 2017-12-12 16:05:49 to 16:10:40
# Attribute pct total min max avg 95% stddev median
# ============ === ======= ======= ======= ======= ======= ======= =======
# Count 0 74
# Exec time 91 25s 95us 7s 334ms 3s 1s 176us
# Lock time 99 25s 37us 7s 334ms 3s 1s 63us
# Rows sent 0 69 0 1 0.93 0.99 0.25 0.99
# Rows examine 0 69 0 1 0.93 0.99 0.25 0.99
# Query size 0 10.04k 139 139 139 139 0 139
# String:
# Databases x
# Hosts xxx.xxx.xxx.xxx
# Users x
# Query_time distribution
# 1us
# 10us #
# 100us ################################################################
# 1ms
# 10ms
# 100ms
# 1s ######
# 10s+
# Tables
# SHOW TABLE STATUS FROM `x` LIKE 's_core_sessions'\G
# SHOW CREATE TABLE `x`.`s_core_sessions`\G
# EXPLAIN /*!50100 PARTITIONS*/
SELECT data, expiry, modified FROM s_core_sessions WHERE id = '1550ee8c7a41e04001cbe7f03e634910170323e39f1e3b78e9fe9f169acd0145' FOR UPDATE\G
Hallo lbmh,
kannst du mir bitte noch sagen welches Script/Programm/Plugin du nimmst um diese Werte zu ermitteln?
Dann kann ich nachsehen wie das eigentlich berechnet wird, bzw. was die Datenbasis ist.
Außerdem wäre ein
SHOW TABLE STATUS like 's_core_sessions'
mal interessant!
Bei mir ist das Ergebnis:
s_core_sessions InnoDB 10 Compact 473 450 212992 0 81920 0 2017-08-31 10:36:27 utf8_bin
Hey,
wichtig wäre vielleicht auf wieviele Plugins installiert sind, da diese natürlich auch Eingriff auf das Session Handling haben. Vielleicht deaktivierst du die mal testweise und schaust dann? Hört sich vielleicht komisch an, aber dadurch lässt sich so manche Ursache finden.
LG Andre
Der Query scheint ja zu sein „SELECT data, expiry, modified FROM s_core_sessions WHERE id = ‚xxx‘ FOR UPDATE\G“
Hauptsächlich hat er wohl ein Problem mit der LOCK-Time, was bei diesem Query auch kein Wunder ist.
Ich denke das hat hiermit zu tun: Shopware Session handling
Auf Anhieb würde ich also entweder auf wirklich viele Sessions tippen, oder aber auf ein schlechtes Plugin.
Du könntest mal testweise das Session Locking abschalten und schauen ob es sofort besser wird:
'session' => array(
'save_handler' => 'db',
'locking' => false
)
Hatten wir auch. Sessions sollten ab gewisser Shop Größe / Benutzer aus der MySQL DB rausgenommen werden und über Redis oder Memcached gelöst werden. Funktioniert bei uns wunderbar, wobei Memcached Probleme mit den Sessions im Backend hat. https://issues.shopware.com/issues/SW-20416
Es liegt auch ggf. an der eingesetzten memcached Version: Issues · php-memcached-dev/php-memcached · GitHub;
Der Fehler ist auch für die Frontend Session gültig.
Hi,
danke für die vielen Antworten.
ich habe das Sessionlocking in der config ausgeschaltet, das hatte aber keinen Effekt.
Ich habe jezt memcached installiert. Der deamon funktioniert und ich kann Daten speichern.
Ich habe in der config das hier eingefügt um das Sessionhandling im Frontend auf memcached zu stellen.
,
'session' => array(
'save_handler' => 'memcached',
'save_path' => "localhost:11211",
)
Muss ich noch etwas umstellen oder so damit es funktioniert? Ich kann jezt nurnoch Seiten aufrufen, die schonmal geladen wurden. Ich bekomme keine Antwort vom Server.
php Error log sagt:
PHP Fatal error: Uncaught exception 'Zend_Session_Exception' with message 'Zend_Session::start() - D:\\xampp56\\htdocs\\shopwareTest\\engine\\Library\\Zend\\Session.php(Line:491): Error #2 session_start(): open(localhost:11211\\sess_ee41905c24a76ded0c558d8fe315ce0a71f6346759d5f2093efed925f961f9f0, O_RDWR) failed: Invalid argument (22)\r\nD:\\xampp56\\htdocs\\shopwareTest\\engine\\Library\\Zend\\Session.php(Line:501): Error #2 session_write_close(): open(localhost:11211\\sess_ee41905c24a76ded0c558d8fe315ce0a71f6346759d5f2093efed925f961f9f0, O_RDWR) failed: Invalid argument (22)\r\nD:\\xampp56\\htdocs\\shopwareTest\\engine\\Library\\Zend\\Session.php(Line:501): Error #2 session_write_close(): Failed to write session data (files). Please verify that the current setting of session.save_path is correct (localhost:11211)' in D:\\xampp56\\htdocs\\shopwareTest\\engine\\Library\\Zend\\Session.php:504\nStack trace:\n#0 D:\\xampp56\\htdocs\\shopwareTest\\engine\\Shopware\\Components\\DependencyInjection\\Bridge\\Session.php(105): Zend_Session::start(Array)\n#1 D:\\xampp56\\htdocs\\sho in D:\\xampp56\\htdocs\\shopwareTest\\engine\\Library\\Zend\\Session.php on line 504, referer: https://shopTest.de/ziele/?p=1
Ohne memcached funktioniert alles, nur halt langsam.
Zudem habe ich die Webseite als Lokale Testumgebung aufgesezt und bei der Originalseite SSD’s eingebaut. Da sowohl lokal als auch in der Live version immernoch dieses krasse Geschwindigkeitesproblem ist und die Datenbank wie gesagt nicht überladen ist kann wohl davon ausgehen, dass Hardware/Datenbank nicht das Problem sind. Der Shop ist wirklich nicht groß. Ich habe auch mal alle Plugins(ausser Template) ausgeschaltet, dies hatte aber keine Wirkung. Mir wäre auch nicht bewusst, was eines der installierten Plugins mit dem Sessionhandling zu tun hätte.