Danke.
Habe den Test auch gemacht und jetzt weiß ich auch wie du auf die 1,2s kommst.
Ich rede von der TTFB (erste gelb markierte Zeile im Bild) und du redest von der gesamten Ladezeit inklusive dem „info“ Ajax Request der asynchron im Hintergrund läuft und der Nutzer nichts davon spürt.
Bei uns lag alleine die TTFB bereits bei über 700ms - hätte das oben direkt genauer beschreiben sollen 
SSDs beim Hosting im Einsatz?
Hi @AndreHerking ,
SSD ist im Einsatz.
Geht es jetzt überhaupt noch schneller? - die Ladezeiten sind enorm gut
https://eseom-shopware-6-demo.eseom.de/
Hi,
darf man fragen, auf was für einem System der eseom-shopware-6-demo läuft?
Also ein selbstverwalteter Server oder ein Hosting-System?
Der ist ja echt super schnell !!!
Gruß,
Werner.
Hi Werner,
ist ein CloudServer von Alfahosting.
Haben hier Debian GNU/Linux 9 (stretch) / 64 bit installiert und selbst die einzelnen Konfigurationen für MariaDB, nginx und PHP vorgenommen.
Der Server hat 24GB Ram, CPU Intel® Xeon® CPU E5-2660 v3 @ 2.60GHz, 500GB SSD.
Viele Grüße und ein schönes Wochenende
Dominik
[@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski “Moritz Naczenski”)
Ich habe gesehen, dass du vor längerem in einem anderen Post geschrieben hattest, dass Redis bald unterstützt werden würde - ist das jetzt bereits der Fall?
Naja Redis soll bereits funktionieren. Wenn man es nutzt und Probleme gibt, wird es wohl heißen, dass es nicht offiziell unterstützt wird. Wenn man sagt, dass sowas zB für große Shops wichtig ist und auf die SW6 EE verweist, dass sowas ja möglich sein muss wenn es sogar eine EE Version gibt, wirst du auf Symfony verwiesen.
Aber ich würde mir da keine große Hoffnung machen. Das Caching scheint in SW6 noch allgemein Probleme zu haben.
Der Cache wächst schnell und wird richtig groß. Mal mit einem Tool die Sitemap abklappern und der Cache liegt bei 8GB in kurzer Zeit. Einen Fix, dass dieser nicht so extrem groß wird, gibts eigentlich. Der wird nur nicht released. Auch wenn auf der SCD noch gesagt wurde, man möchte jetzt lieber mehr kleine Releases machen, gabs seitdem keinen einzigen Release, obwohl schon einige Fixes fertig sind.
Und obwohl der Cache so groß ist, haben auch wir das Problem, dass der scheinbar nicht immer greift und die Seite immer mal wieder langsam ist.
So geht ein Arbeitskollege auf eine URL bis diese mit etwa 100ms durch Caching antwortet. Gehe ich direkt danach auf die gleiche URL und erhalte 800ms+. Da greift also das Caching nicht. Und der Shop ist nicht live. Da ist keine Last auf dem Server, der Schwankungen erklären würde.
Und obwohl der Cache so groß ist, haben auch wir das Problem, dass der scheinbar nicht immer greift und die Seite immer mal wieder langsam ist.
So geht ein Arbeitskollege auf eine URL bis diese mit etwa 100ms durch Caching antwortet. Gehe ich direkt danach auf die gleiche URL und erhalte 800ms+. Da greift also das Caching nicht. Und der Shop ist nicht live. Da ist keine Last auf dem Server, der Schwankungen erklären würde.
Kommt etwas auf den Context an, in dem sich der User befindet. Du wärmst ja nur den „default“ Context des Sales-Channels auf. Sobald du ein anderes Lieferland wählst oder bspw. einen Warenkorb besitzt, kann sich theoretisch dein Context ändern und du bekommst einen eigenen Cache. Das muss also nicht zwangsweise falsch sein. Müsste man sich im Detail ansehen, was bei deinem Beispiel jetzt die Ursache ist.
Und obwohl der Cache so groß ist, haben auch wir das Problem, dass der scheinbar nicht immer greift und die Seite immer mal wieder langsam ist.
So geht ein Arbeitskollege auf eine URL bis diese mit etwa 100ms durch Caching antwortet. Gehe ich direkt danach auf die gleiche URL und erhalte 800ms+. Da greift also das Caching nicht. Und der Shop ist nicht live. Da ist keine Last auf dem Server, der Schwankungen erklären würde.Kommt etwas auf den Context an, in dem sich der User befindet. Du wärmst ja nur den „default“ Context des Sales-Channels auf. Sobald du ein anderes Lieferland wählst oder bspw. einen Warenkorb besitzt, kann sich theoretisch dein Context ändern und du bekommst einen eigenen Cache. Das muss also nicht zwangsweise falsch sein. Müsste man sich im Detail ansehen, was bei deinem Beispiel jetzt die Ursache ist.
Das soll bedeuten, dass im Grunde jeder User den HTTP-Cache von vorn aufbaut? Oder welcher Cache ist User-spezifisch? Weil wenn ein Klick auf den Warenkorb, den kompletten HTTP-Cache obsolete macht pro User, dann macht der Cache ja recht wenig Sinn? Weil die gleiche Produktseite, muss eigentlich nicht pro User gecached sein.
Ich weiß, darauf wird es wahrscheinlich keine zufriedenstellende Antwort geben. Wird Varnish unterstützt oder ist das geplant? Da SW6 ja sowieso sehr viel auf Ajax aufbaut, kann ich mir vorstellen, dass Varnish wahrscheinlich garnicht so schwer zu integrieren wäre. Es müsste nur am Besten per Header vom Shop mitgeteilt werden, ob eine Seite Varnish-Cachefähig ist oder nicht.
Hallo,
wow, stimmt ja, der Cache wird ja echt riesig…unglaublich
Hab gerade 1000 Produkte drin, okay mit z.T. einigen Varianten, aber trotzdem,
hab den Cache aufwärmen lassen und bin bei ca. 6 GB.
Den Cache für die 1000 Produkte aufzuwärmen ist jetzt auch nicht gerade eine so schnelle Geschichte…
Wenn wir da alle Produkte mal drin haben (ca. 50.000), wird das aber lustig.
Danke für die Info.
Das mit dem “nicht immer greift” kann ich allerdings so nicht nachvollziehen, nachdem der dann mal aufgewärmt war,
habe ich dann immer eine durchweg schnelle Antwortzeit erhalten, der Cache hat dann immer gegriffen.
Das mit dem Warenkorb verstehe ich nicht, der wird ja eh per Ajax geladen und sollte ja weder im Cache sein,
noch auf den Cache Auswirkungen haben.
Gruß,
Werner.
hab den Cache aufwärmen lassen und bin bei ca. 6 GB.
Wie wärmst du den Cache auf?
bin/console cache:warmup ?
Der Befehl dauert bei mir nur wenige Sekunden und sagt, ist fertig. [OK] Cache for the „prod“ environment (debug=false) was successfully warmed.
Hab nicht das Gefühl, dass da was passiert. Evtl. paar Cache-PHP-Klassen erzeugen, aber kein HTTP-Cache.
Oder per Crawler?
Manchmal wird auch der alte Cache Ordner nicht gelöscht bei cache:clear und es erstellt einen zusätzlichen Ordner.
@Exe
So geht ein Arbeitskollege auf eine URL bis diese mit etwa 100ms durch Caching antwortet. Gehe ich direkt danach auf die gleiche URL und erhalte 800ms+.
Genau diesem Problem wollte ich auf den Grund gehen - bei SW5 ist es aber ebenfalls so - ich bin mir mittlerweile nicht sicher ob das etwas mit der DNS TTL zu tun hat, da wir bereits etliche Einstellungen mit Nginx, APCu, OPcache und MariaDB durchgetestet haben.
Mit den jetzigen Einstellungen ist SW6 schon echt schnell, allerdings weiß ich nicht ob das mit dem Cronjob, der alle Seiten besucht bei größeren Shops noch durchführbar ist.
Hier kannst du dir das Ergebnis anschauen:
https://eseom-shopware-6-demo.eseom.de/
Der Cache ist erstmal dafür da, den ersten Aufruf schnell zu halten. Die Folgeaufrufe sind je nach Conext ( anderes Lieferland, dadurch andere steuern) ggf. separat gecached, weil die Preise sich halt ändern können. Die Logik ist schon so, dass die Seite neu ausgeliefert wird, wenn es nötig ist (anderer Context). Solange der Context, den du am Sales Channel definierst, sich nicht ändert, sind die Seiten auch gecached für die User. Pauschal kann man das halt nicht beantworten.
Bzgl. der Größe gab es ja kürzlich eine Optimierung, die auch im nächsten Release drin ist. Sollte nächste Woche glaube kommen.
Wenn der warump nur ein paar Sekunden dauert, dann scheint er bei dir nicht zu laufen. Das wird deutlich länger laufen, je nach Anzahl der Produkte.
hab den Cache aufwärmen lassen und bin bei ca. 6 GB.
Wie wärmst du den Cache auf?
bin/console cache:warmup ?
Der Befehl dauert bei mir nur wenige Sekunden und sagt, ist fertig. [OK] Cache for the „prod“ environment (debug=false) was successfully warmed.
Hab nicht das Gefühl, dass da was passiert. Evtl. paar Cache-PHP-Klassen erzeugen, aber kein HTTP-Cache.Oder per Crawler?
Ich habe das nicht über die console gemacht, sondern im admin über Einstellungen -> Caches & Indizes -> Cache löschen und aufwärmen
Dann kommen auch immer die Mitteilungen wieviele Seiten er noch verarbeiten muß, hat bei mir irgendwo bei 6500 Seiten angefangen, zählt dann langsam runter.
Wenn das bei dir nur wenige Sekunden dauert, dann stimmt was nicht.
6 GB (in meinem Fall) an strukturierten Daten in wenigen Sekunden zu erzeugen, ist doch etwas utopisch auf einem normalen Server-Rechner.
@WernerBu
Hast du einmal in den /var/cache/ Ordner geschaut?
Wie viele Ordner siehst du da?
Es sollten meiner Meinung nach genau 2 sein - „composer“ und dein Cache „prod_XXXXXXXXXXXXXX“…
[@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski “Moritz Naczenski”)
Der erste Seitenaufruf ist eben gerade das, was ich in diesem Thread diskutieren wollte.
Aktuell dauert die TTFB 700-900ms für den ersten Seitenaufruf - mit aufgewärmten HTTP-Cache.
Jeder weitere Seitenaufruf dann lediglich 50-70ms - ohne Browser-Cache.
Nach 10-30 Minuten ohne Seitenaufruf liegt die Ladezeit wieder bei 700-900.
Wir haben hier bereits die unterschiedlichsten Konfigurationen an APCu, OPcache, MariaDB und nginx durchgetestet - leider lässt sich das nicht beheben.
Habt ihr hier vielleicht noch eine Erklärung?
Liegt es vielleicht an der DNS-TTL?
Hallo,
ja genau, richtig und das prod_XXX Verzeichnis ist eben auf fast 6 GB langsam angewachsen durch den Cache Aufwärmprozess.
Gruß,
Werner.
Haben jetzt noch http/2 Push eingerichtet und sparen uns somit noch einmal 400 ms Ladezeit:
Mit den beiden Ajax-Requests “api-access” und “info” sind es 800 ms Ladezeit und ohne liegen wir jetzt bei 370ms.
Da die Ajax-Requests im Hintergrund laufen ist die Ladezeit von 370ms wirklich beeindruckend.
Für nginx haben wir hierzu folgendes eingetragen:
# BEGIN - HTTP2/PUSH
http2_push_preload on;
add_header Link "; as=style; rel=preload;";
add_header Link "; as=script; rel=preload;";
add_header Link "; as=font; rel=preload;";
add_header Link "; as=image; rel=preload;";
add_header Link "; as=image; rel=preload;";
# END - HTTP2/PUSH
Wenn jetzt noch folgendes Ticket umgesetzt wurde und wir auf webp umsteigen können, wird die Ladezeit laut Google für Desktop noch einmal um 300 ms verringert!
https://issues.shopware.com/issues/NEXT-9366
Gerne voten!
