Hi, ich hab für unseren Hoster ein paar Vergleiche durchgeführt. Den Einen oder Anderen hier wird das sicher auch interessieren. Zum Cache: Es handelt sich um den Frontendcache(httpCache) von Shopware. Dieser Cache ist etwa 6 Monate alt und befindet sich derzeit noch in der Beta. Insgesamt ist das Plugin wohl eher als Notlösung zu betrachten, so empfiehlt Shopware selbst, fals möglich, Varnish zu nutzen, welches im Vergleich „extrem performanter“ sei. Zu den Messungen: Gemessen wurden die Ladezeiten auf meinem lokalen Rechner mit Hifle von Firebug. Bei den angegebenen Zeiten handelt es sich um die Auslieferungszeit der HTML durch den Server (CSS, JS, Bilder machen bei einem PHP-Cache naheliegenderweise keinen Unterschied) Startseite, erster Aufruf: Ohne Cache: 3,95sec | 3,88sec | 4,14sec Mit Cache: 4,03sec | 4,09sec | 4,02sec Startseite, Folgeaufrufe Ohne Cache: 641ms | 687ms | 735ms Mit Cache: 562ms | 484ms | 500ms Kategorieseite, erster Aufruf: Ohne Cache: 4,72sec | 4,63sec | 4,78sec Mit Cache: 4,74sec | 4,69sec | 4,70sec Kategorieseite, Folgeaufrufe: Ohne Cache: 953ms | 938ms | 907ms Mit Cache: 563ms | 531ms | 500ms Artikelseite, Folgeaufrufe (mit Einschränkungen, siehe unten): Ohne Cache: 937ms | 859ms | 859ms Mit Cache: 532ms | 531ms | 485ms Anmerkungen: Auf den Artikeldetailseiten hängt der Unterschied davon ab, ob weitere Boxen geladen werden - also ganz konkret Dinge wie „Kunden kauften auch“, „Kunden haben sich auch angesehen“, etc… Gibt es solche Boxen für den Artikel, ist der Unterschied so groß, wie im Beispiel - gibt es diese Boxen nicht, ist sowohl mit, als auch ohne Cache die Auslieferung als gleich zu betrachten. (offtopic: das kann doch eigentlich nur die Datenbankabfrage sein, oder? ist die wirklich so schlecht?) Auf den Listing-Seiten kommt es bei Verwendung der Filter / Sortierfunktion zu einer merkwürdigen Umleitung der Seite, wodurch sich die Gesamtladezeit mit Cache eher etwas verschlechtert. Leider wird das in meinen Tests auch nicht durch die Einsparung bei Wiederholung des Filters ausgeglichen. Fazit: Die Unterschiede sind deutlich messbar und was noch wichtiger ist: deutlich spürbar. Nach dem ersten Erstellen der Seiten werden die Seiten bei allen Folgeaufrufen spürbar schneller aufgebaut und gestalten das Surfen auf der Seite insgesamt viel angenehmer. Der Unterschied wird dabei umso größer werden, je mehr Zugriffe parallel erfolgen, da die Belastung des Servers mit Cache deutlich geringer ausfallen dürfte. Werden viele Filter und Sortierfunktionen genutzt, müsste man nochmal testen und abwägen.
Hallo, passt nicht ganz hierhin, aber trotzdem. Ich hatte in anderen Posts behauptet noch keine Probleme mit httpcache gehabt zu haben. Das hat sich geändert, allerdings nicht in einer live-Umgebung, sondern auf einem Passwort geschütztem nginx Server. Ich konnte mich nicht mehr in das Backend einloggen. Fehlerhafte Passwörter sind erkannt und normal beantwortet worden, aber ein korrekter Login erzeugte keine Reaktion. Tiefer ins Detail bin ich nicht mehr eingestiegen. hth
ich glaube das liegt eher daran das du nicht die passwörter übergibst. irgendwo in der hilfe war das mal am beispiel der api erklärt worden. prüfe mal ob api geht, wenn dort das selbe dann werden deine übergaben nicht gespeichert. kann aber auch sein das ich mich irre weil freitag ist 
mmh, ohne httpcache funktioniert aber alles. Wie auch immer, ich suche mal nach den API Erklärungen
Cache komplett gelerrt? Diese Probleme hatte ich noch nie
[quote=“hth”]passt nicht ganz hierhin, aber trotzdem. Ich hatte in anderen Posts behauptet noch keine Probleme mit httpcache gehabt zu haben. […] Ich konnte mich nicht mehr in das Backend einloggen. Fehlerhafte Passwörter sind erkannt und normal beantwortet worden, aber ein korrekter Login erzeugte keine Reaktion.[/quote] Das ist genau die Art Antwort, die ich nicht lesen will Meine Befürchtung ist eben auch, dass erstmal alles läuft und dann später unerwartete Fehler im Backend, oder was viel schlimmer wäre, beim Kunden auftreten, bei denen wir erstmal auf die Idee kommen müssen, dass es mit dem Caching zusammenhängt. Ich hatte auch schon vergeblich nach einer offiziellen Einschätzung zum Stand und möglichen Fehlverhalten gefragt. Wie habt ihr das Plugin ohne Zugriff ins Backend wieder deaktiviert?
phpmyadmin ist dein freund und helfer dann aus einer 1 eine 0 machen
[quote=“Ade”][quote=“hth”]passt nicht ganz hierhin, aber trotzdem. Ich hatte in anderen Posts behauptet noch keine Probleme mit httpcache gehabt zu haben. […] Ich konnte mich nicht mehr in das Backend einloggen. Fehlerhafte Passwörter sind erkannt und normal beantwortet worden, aber ein korrekter Login erzeugte keine Reaktion.[/quote] Das ist genau die Art Antwort, die ich nicht lesen will Meine Befürchtung ist eben auch, dass erstmal alles läuft und dann später unerwartete Fehler im Backend, oder was viel schlimmer wäre, beim Kunden auftreten, bei denen wir erstmal auf die Idee kommen müssen, dass es mit dem Caching zusammenhängt. Ich hatte auch schon vergeblich nach einer offiziellen Einschätzung zum Stand und möglichen Fehlverhalten gefragt. Wie habt ihr das Plugin ohne Zugriff ins Backend wieder deaktiviert?[/quote] Ich habe nur die Config Datei wieder per FTP in den Originalzustand versetzt, danach ging alles. Die Caches habe ich nicht angefasst. Komisch war nur, dass einen Tag vorher sowohl Backend und Frontend funktioniert haben und der Passwortschutz unverändert gewesen ist. da hatte ich auch httpcache über das Backend gelöscht. Nun ja, ich warte ab, bis er freigegeben wird.