Wir sind mit unserem Onlineshop auf einen neuen Server umgezogen.
Seit dem Umzug haben wir in einigen Bereichen sehr lange Ladezeiten (10-20 Sekunden!), z.B., wenn man bereits Artikel in den Warenkorb gelegt hat und dann seine Zugangsdaten eingibt um sich einzuloggen. Macht man das mit einem leeren Warenkorb geht das deutlich schneller. Auch das Ändern der Zahlungsarten zieht lange Wartezeiten mit sich.
Was können wir machen, um das Problem zu lokalisieren?
Hoster fragen, Logs einsehen, Shopware debuggen, Shopware Einstellungen überprüfen ala Cache Einstellungen, Server Performance überprüfen, Ist PHP APC/u / OPCache am laufen, ist der Cache aufgewärmt, welche PHP Version läuft usw. usw.
Gibt zig Wege und Dinge an denen es liegen kann.
Und ohne Link kann man sowieso nur raten …
Hier der Link zum Shop: www.biologischverpacken.de
Der oben genannten Punkte haben wir bereits abgearbeitet… 
Also ich find den Shop recht ok von der Performance. Kategorien sind fix und Warenkorb ist noch akzeptabel. 1-2 Sekunden dann ist die Sidebar fertig.
Der Warenkorbaufruf selbst dauert länger. Da dort kein Cache greift, kann es eigentlich nur direkt der Server bzw. PHP sein.
Welche PHP Version, welche Memory Limits? Welcher Hoster?
Hallo @dr@bionatic.de,
10-20 Sekunden Ladezeit kann ich im Shop nicht nachvollziehen. Eine Ladezeit von ~20 Sekunden ist in der Regel durch eine Theme-Kompilierung bedingt - evtl. wurde das beim Cache Leeren veresehentlich mit gelöscht und nicht wieder aufgebaut.
Der Shop ist zwar nicht besonders schnell, aber auch nicht extrem langsam. Die TTFB-Werte bei einem Reload einer Seite oder beim „Wandern“ von einer Artikeldetailseite zum nächsten/vorhergehenden Artikel sind nicht besonders konsistent. Auch ist der Effekt des HTTP-Caches oft nicht erkennbar. Ladezeiten der Kategorielistings und Artikeldetailseiten ohne http-Cache zwischen 500ms - 1 Sekunde sind grundsätzlich in Ordnung. Merkwürdig ist, das bei einem Reload der HTTP-Cache oft keine drastische Verkürzung der Ladezeit zeit. Diese sollte dann ~80-200ms liegen.
Der Warenkorbaufruf ist sehr langsam, das liegt aber an dem verwendeten Hostingpaket. Meiner Ansicht nach sollte man auch bzgl. des verwendeten PHP-Releases (Aktualisierungen) noch mal mit dem Unternehmen Rücksprache halten. Das hat aber nichts mit der Performance zu tun.
Die Checkout-Ladezeiten sind eigentlich ein klarer Indikator das Hostingpaket zu wechseln. Hier zeigt sich die „echte“ Leistungsfähigkeit des Paketes ohne beschönigende Kosmektik diverser Caching-Systeme.
Viele Grüße
HTH
Also ich find den Shop recht ok von der Performance. Kategorien sind fix und Warenkorb ist noch akzeptabel. 1-2 Sekunden dann ist die Sidebar fertig.
Der Warenkorbaufruf selbst dauert länger. Da dort kein Cache greift, kann es eigentlich nur direkt der Server bzw. PHP sein.
Welche PHP Version, welche Memory Limits? Welcher Hoster?
Wir sind bei Mittwald mit einem Managed vServer XXL 9.0 - SSD. Es läuft PHP 5.6 FPM (P+). In der Server-Konfiguration im Backend von Shopware sind alle Felder mit einem grünen Haken versehen / Memory Limit steht bei 256M.
Also ich kann es überhaupt nicht nachvollziehen, es geht alles flott wie es sein soll. Auch der Warenkorb Aufruf geht bei mir so flott wie es sein soll.
Was man aber in jedem Fall machen sollte - GZIP ist garnicht aktiv, hier unbedingt aktivieren. Das wird noch einmal ein paar Millisekündchen bringen.
PS: Ich wette um 10 EUR das dieser XXL Server gerade mal eine Auslastung von 5% hat - ich nehme auch mal an, da läuft nicht nur dieser Shop drunter? 
Solltest vielleicht mal nachfragen, wie die Auslastung im Durchschnitt ist - evtl hast du ja auch selber Statistiken - und evtl. downgraden. Ansonsten schmeißt du ja monatlich über 100 EUR zum Fenster raus. Damit sich das mehr anhört - Pro Jahr schmeißt du damit sicherlich 1.200 EUR aus dem Fesnter 
Wir sind bei Mittwald mit einem Managed vServer XXL 9.0 - SSD. Es läuft PHP 5.6 FPM (P+). In der Server-Konfiguration im Backend von Shopware sind alle Felder mit einem grünen Haken versehen / Memory Limit steht bei 256M.
Die Ladezeiten reflektieren die Struktur des Hostingpaketes, daran ändert sich auch nichts, wenn man das RAM-Skript-Limit hochsetzt oder die Anzahlder vCores erhöht.
Die LAdezeit der Ajax-Requests für die Warenkorb-Sidebar ist auf jeden Fall deutlich schneller für den Preis zu haben. Ob das in der Conversion einen Unterschied macht, steht natürlich auf einem anderen Blatt.
Also ich kann es überhaupt nicht nachvollziehen, es geht alles flott wie es sein soll. Auch der Warenkorb Aufruf geht bei mir so flott wie es sein soll.
Bei folgendem Aktionspfad habe ich wiederholt die Probleme festgestellt (und habe sie auch weiterhin):
> Registrieren und abmelden, damit man ohne Anmeldung einen Artikel in den Warenkorb legen kann
> Dann „zur Kasse“
> Dann seine Zugangsdaten eingeben.
Jetzt dauert das Laden des Warenkorbes bei mir mind. 10 Sekunden…
Bei folgendem Aktionspfad habe ich wiederholt die Probleme festgestellt (und habe sie auch weiterhin):
> Registrieren und abmelden, damit man ohne Anmeldung einen Artikel in den Warenkorb legen kann
> Dann „zur Kasse“
> Dann seine Zugangsdaten eingeben.
Jetzt dauert das Laden des Warenkorbes bei mir mind. 10 Sekunden…
Der Wechsel nach Registrierung zur nächsten Seite des Checkouts dauert in der Tat ~12 Sekunden. An dieser Stelle kann es unter bestimmten Umständen zu längeren Ladezeiten kommen. Allerdings sollte sich das dann bei einem preisgünstigen Paket nicht reproduzierbar bei 12 Sekunden liegen, sondern sagen wir mal bei 5 Sekunden.
Das ist ebenso wie die ~1.6 Sekunden für den ersten Ajax-Aufruf bei der Warenkorb-Sidebar in der Struktur des Hostingpaketes bedingt. Das wäre auch mit dem günstigsten vServer-Paket dort genauso schnell.
Ich zitiere mich nochmal selbst, da das wohl unter gegangen ist
Was man aber in jedem Fall machen sollte - GZIP ist garnicht aktiv, hier unbedingt aktivieren. Das wird noch einmal ein paar Millisekündchen bringen.
Und wie @hth bereits sagte, hat ab einen gewissen Maß die Hardware des Servers überhaupt rein garnichts mit der Performance zu tun. Das ist ein Fehlgedanke vieler die meinen „Oh der Shop ist aber langsam, ich brauche jetzt einen großen Server“. Totaler Blödsinn, der Einzige wer sich freut ist der Hoster über Einnahmen :)
Der Wechsel nach Registrierung zur nächsten Seite des Checkouts dauert in der Tat ~12 Sekunden. An dieser Stelle kann es unter bestimmten Umständen zu längeren Ladezeiten kommen. Allerdings sollte sich das dann bei einem preisgünstigen Paket nicht reproduzierbar bei 12 Sekunden liegen, sondern sagen wir mal bei 5 Sekunden.
Das ist ebenso wie die ~1.6 Sekunden für den ersten Ajax-Aufruf bei der Warenkorb-Sidebar in der Struktur des Hostingpaketes bedingt. Das wäre auch mit dem günstigsten vServer-Paket dort genauso schnell.
Und an der Stelle versuchen wir zu ermitteln, warum die Ladezeiten (reproduzierbar) so lange sind und finden die Quelle des Übels nicht…
Ich zitiere mich nochmal selbst, da das wohl unter gegangen ist
Was man aber in jedem Fall machen sollte - GZIP ist garnicht aktiv, hier unbedingt aktivieren. Das wird noch einmal ein paar Millisekündchen bringen.
Danke für den Tipp, das habe ich schon aufgenommen und lasse es aktivieren.
Unabhängig davon schreibst du ja, dass es ein paar Millisekunden bringen kann. Schön, wenn es das tut, aber das Problem, warum das Laden an oben beschriebener Stelle so lange dauert, scheint dann ja noch an anderer Stelle zu liegen. Vielleicht hat noch jemand eine Idee?
Die Millisekunden waren auf die Gesamt Performance bezogen -
Welche Shopware Version hast du im Einsatz?
Weiterhin empfehle ich dir einfach mal Shopware zu debuggen und darüber hinaus folgendes Thema:
http://forum.shopware.com/discussion/31303/immer-noch-erhebliche-performance-probleme/p1
Ich tippe auch evtl. auf ein Dritt Plugin was hier Performance zieht. Testweise auch einfach mal evtl. alle Dritten Plugins deaktivieren und erneut testen.
Der Wechsel nach Registrierung zur nächsten Seite des Checkouts dauert in der Tat ~12 Sekunden. An dieser Stelle kann es unter bestimmten Umständen zu längeren Ladezeiten kommen. Allerdings sollte sich das dann bei einem preisgünstigen Paket nicht reproduzierbar bei 12 Sekunden liegen, sondern sagen wir mal bei 5 Sekunden.
Das ist ebenso wie die ~1.6 Sekunden für den ersten Ajax-Aufruf bei der Warenkorb-Sidebar in der Struktur des Hostingpaketes bedingt. Das wäre auch mit dem günstigsten vServer-Paket dort genauso schnell.
Und an der Stelle versuchen wir zu ermitteln, warum die Ladezeiten (reproduzierbar) so lange sind und finden die Quelle des Übels nicht…
Die Ladezeiten der Checkout-Controller liegen im Rahmen der Erfahrungswerte, die Kunden von mir mit diesem Hostingpaket-Typ gemacht haben. Es gibt hier einfach keinen Grund mehr weiter zu suchen.
Dieser manchmal langsame Wechsel bei Anlage eines Kundenkontos zu Shipping/Payment scheint an PaypalPlus zu liegen, zumindest habe ich es bislang nur in dieser Konstellation gesehen. Aber, wie schon gesagt, auch bei diesen ungünstigen Fällen, liegen die 12 Sekunden am Hostingpaket.
Die vServer dort haben einige nette Features und Macken an anderer Stelle. Welche Funktionen wichtiger sind, ist eine Entscheidung, die letztlich jeder selber treffen muss.
Viele Grüße
HTH
Die Millisekunden waren auf die Gesamt Performance bezogen -
Welche Shopware Version hast du im Einsatz?
Weiterhin empfehle ich dir einfach mal Shopware zu debuggen und darüber hinaus folgendes Thema:
http://forum.shopware.com/discussion/31303/immer-noch-erhebliche-performance-probleme/p1
Ich tippe auch evtl. auf ein Dritt Plugin was hier Performance zieht. Testweise auch einfach mal evtl. alle Dritten Plugins deaktivieren und erneut testen.
Wir arbeiten mit Shopware 5.1.4. Das mit dem Testsystem ist jetzt in Arbeit um die Dritten Plugins ausschalten und nacheinander wieder reaktivieren zu können.
Ich melde mich, wenn es etwas Neues gibt.
Kurze Zwischenmeldung: In der Testumgebung haben wir alle Plugins deaktiviert, jetzt läuft es deutlich schneller. Im nächsten Step werden wir die Plugins nach und nach reaktivieren und ermitteln, welches Plugin zu dem Problem führt.
Was man aber in jedem Fall machen sollte - GZIP ist garnicht aktiv, hier unbedingt aktivieren. Das wird noch einmal ein paar Millisekündchen bringen.
Hey kayyy,
folgende Rückmeldung unseres technischen Shop-Betreuers:
Bezüglich der Gzip Encodierung, ich habe da gerade mal nachgeschaut, also bei mir wird die Seite per GZIP übertragen, siehe Screenshot
Das ist der Request Header und nicht der Response Header des Servers.
Der Server setzt gzip nur bei dem Content-Typ CSS ein und nicht bei Javascript und HTML. Sieht man z. B. in den Developer Tools von GoogleChrome. Dort gibt es eine Spalte Content Encoding. Die Datei mit einem <> im Piktogramm am Anfang der Zeile ist der Content-Typ text/html und CSS bzw. JS sind anhand der Abkürzungen im Piktogramm erkennbar.
Das ist der Request Header und nicht der Response Header des Servers.
Der Server setzt gzip nur bei dem Content-Typ CSS ein und nicht bei Javascript und HTML. Sieht man z. B. in den Developer Tools von GoogleChrome. Dort gibt es eine Spalte Content Encoding. Die Datei mit einem <> im Piktogramm am Anfang der Zeile ist der Content-Typ text/html und CSS bzw. JS sind anhand der Abkürzungen im Piktogramm erkennbar.
Ok, das leite ich mal so als Info weiter. Danke für den Hinweis.