Hallo,
ist es irgendwie möglich, die Themes zu kompilieren, ohne dabei den gesamten Http-Reverse-Proxy zu löschen?
Letzteres zu erstellen, dauert ja ne ziemlich lange Weile und nutzt ziemliche Server-Resourcen.
Ich verstehe nicht so ganz, wieso bei kleinen Veränderungen an einer Template-Datei der gesamte (1GB-große) Cache neu erstellt werden sollte.
Hat jemand eine Idee?
MFG
Nils
Die Frage ist eher warum das “ne zimlich lange Weile” dauert ?
Alle Caches zu leeren und das template kompilieren dauert hier manuell ca. 6-8 sec. aber das ist sicher auch von der Größe des Shops abhängig.
möglicherweise hilt auch das: http://community.shopware.com/http-cache
Hallo kulli,
bei 600 Herstellern und ca. 5000 Artikeln (insgesamt etwa 1GB) dauert das Cache aufwärmen etwa 10 bis 15 Minuten. Das Themes kompilieren geht natürlich schon so schnell. Aber beim Cache leeren bzw. Themes neu kompilieren wird (zumindest bei mir) auch automatisch der Http-Proxy-Cache mit gelöscht, wodurch ein erneutes Cache äufwärmen notwendig wird…
MFG
Nils
Guten Morgen,
Das Erstellen des HTTP-Caches (auch „Proxy Cache“) kann eine ganze Weile dauern , da im Prinzip für alle Produkte, Kategorien etc. die nicht Session-abhängigen Teile der Seiten vollständig gerendert und gecached werden müssen.
Unabhängig davon hast Du ja die Möglichkeit den Cache auch über das „Caches“ Menü im Backend zu leeren. Dort kannst Du wählen welche Caches geleert werden können. Wenn Du dort lediglich die beiden Caches für die Templates wählst, bleibt der HTTP Cache auch unberührt.
Hi Nils,
unter Einstellungen -> Caches / Performance -> Reiter Einstellungen -> Themes kannst du auch nur die Theme Kompilierung anstoßen.
Viele Grüße aus Schöppingen
Michael Telgmann
Unabhängig davon hast Du ja die Möglichkeit den Cache auch über das „Caches“ Menü im Backend zu leeren. Dort kannst Du wählen welche Caches geleert werden können. Wenn Du dort lediglich die beiden Caches für die Templates wählst, bleibt der HTTP Cache auch unberührt.
Das ist so nicht ganz korrekt. Wählt man „Themes kompilieren“ wird zwar zunächst nur der Theme-Cache geleert, beim neukompilieren der Themes aber automatisch im Anschluss auch der HTTP-Cache geleert, wie Kenny geschrieben hat.
Warum das so ist? Vermutlich weil sonst gecachte Seiten mit dem alten Theme ausgeliefert werden würden und das System nicht weiß welche Template-Datei gerade geändert wurde und welche Seiten davon eventuell betroffen sein könnten um eventuell nur Teile des Caches neu zu generieren.
Wenn das im Live-Betrieb so ein Problem ist würde ich dazu raten solche Änderungen automatisiert nachts machen zu lassen oder Zugriffszahlen tagsüber analysieren und schauen wann ihr tagsüber wenig Betrieb auf dem Server habt.
Also ich kann dieses Verhalten aktuell nicht bestätigen. Bei 5.2.5 wird der HTTP Cache beim Kompilieren nicht geleert… Zumindest wäre es mir noch nicht aufgefallen.
Meine Empfehlung:
Da Du am Produktivsystem ja sowieso nur alle X-Zeiten mal das Theme kompilierst (hoffe ich jedenfalls 
), würde ich das Kompilieren bei Bedarf auch tagsüber machen und das Cache-Warmup dann in der Nacht anstoßen. Evtl. kannst Du diesem Prozess auch geringe Prio geben, damit die Ressourcen Deiner Maschine nicht komplett gefressen werden.
Ich hab’s gerade nochmal getestet. Der HTTP-Cache wird sogar vor dem Theme kompilieren schon geleert, auch wenn man nur den Haken bei Theme kompilieren anhakt. Außerdem wird er nochmal nach erfolgreichem kompilieren automatisch gelöscht. Auch in SW5.2.5
Eventuell hilft es über die command line den Theme-Cache zu generieren per sw:theme:cache:generate
Kann allerdings sein, dass dort auch automatisch andere Caches mit geleert werden, nicht getestet.
Hi t2oh4e (was auch immer der Name bedeuten mag 
),
ich werds mal mit den CLI commands versuchen. Hab das aber noch nie benutzt und muss mich erstmal reinfuchsen und berichte dann.
Aber bin schon mal froh, dass Andere das auch als Problem/Bug betrachten und dass das wohl nicht so gewollt ist. Sonst hätte ich wieder einen Punkt mehr im Leben, bei dem ich die Welt nicht verstehen/nachvollziehen könnte.
Bis in Kürze!
MFG
Nils
/elektronikhandel-online.de/bin$ php bin/console
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/curl.so' - libnghttp2.so.14: cannot open shared object file: No such file or directory in Unknown on line 0
PHP Warning: Module 'gmp' already loaded in Unknown on line 0
PHP Warning: Module 'mysql' already loaded in Unknown on line 0
PHP Warning: Module 'mysqli' already loaded in Unknown on line 0
PHP Warning: Module 'pdo_mysql' already loaded in Unknown on line 0
No entry for terminal type "dumb";
using dumb terminal settings.
PHP Warning: Module 'ionCube Loader' already loaded in Unknown on line 0
[Sat Aug 20 05:38:05 2016] [warn-ioncube] The ionCube PHP Loader is disabled because of startup problems. (pid 26899)
PHP Fatal error: IC24: ic24.sec.update_domains_retry_interval must be between 1 (1 second) and 300 (5 minutes) in Unknown on line 0
Hm,
habe mal testweise php bin/console in der console eingegeben und erhalte dann nur folgende Fehlermeldung:
Ich schätze mal, dass noch Vorabeiten von mir durchzuführen sind. Hättest du einen Denkanstoß für mich?
MFG
NIls
Ich würde mal die Systemvorraussetzung ganz genau prüfen.
Wie bereits in meinem ersten post angemerkt dauert das viel zu lange. Sieht mir eher nach timeouts aus durch mangelnde Servervorraussetzungen
Bei Dir dürfte CURL nicht installiert oder richtig initialisiert sein, daher die Exception…
@ Kulli
Ich glaube, dass du Themes kompilieren mit Cache aufwärmen verwechselst, könnte das sein?
@Synonymous
Hab gerade mal nachgesehen und folgendes steht in der php-info:
cURL support: enabled
cURL Information 7.50.1
Daher sollte es daran nicht liegen. Hättest du noch eine Vermutung? Vielleicht wegen der noch “zu” neuen PHP 7.0.9-Version oder irgendwo irgendwelche nicht korrekten Schreibrechte oder??
@ alle anderen
ich hatte gar nicht so recht mitbekommen, wieviele Antworten ich hier erhalten hatte und will die Antworten natürlich nicht ignorieren!
@Michael Telgmann
Leider wird auch hier bei mir der gesamte Cache gelöscht
@Synonymous
Egal welche Haken ich entferne. Der Cache wird immer komplett gelöscht. Sogar wenn ich nur oben im Backend “kurz auf Shop-Cache leeren” klicke. Hier dachte ich bisher, dass dort nur kleinere Einstellungen “geleert” werden und nicht direkt der ganze Proxy-Cache… Leider hab ich bisher keine Möglichkeit entdeckt, das Problem zu umgehen. Werds aber weiter testen und bei Erfolg berichten.
MFG
Nils
Ergänzung:
Bei cURL erhalte ich jetzt immerhin schon die Meldung: Permission denied
Noch ein paar Rechte anpassen und dann sollte das zumindest erstmal funktionieren.
@ Kulli
Ich glaube, dass du Themes kompilieren mit Cache aufwärmen verwechselst, könnte das sein?
nein
Hi,
das Kompilieren der Themes erfordert das Neugenerieren des Caches. Beim Neukompilieren ändert sich der Name (Timestamp) der Themedateien, damit Browser die neuen Dateien anfordern und nicht die alten Dateien weiternutzen. Diese neuen Namen müssen in den HTTP-Seiten ja referenziert werden - und entsprechend muss der HTTP-Cache invalidiert werden, da er auf die alten Themefiles verweist.
Von daher ist das nach meinem Verständnis erstmal korrekt so - wenngleich ich deine Frage gut verstehen kann, scheint mir das technisch erstmal notwendig zu sein.
Daniel
Stimmt - muss eigentlich schon allein wegen intermediärer Knoten so sein, da die die Files sonst möglicherweise cachen wenn der Timestamp im HTTP Header nicht modifiziert wird.
Du verwendest hier ja scheinbar auch einen Ioncube Loader Service (ic24), der das Problem auslöst. Versuche mal diesen zu dekativieren. Nachdem der Ioncube Loader mit PHP7 noch nicht funktioniert, könnte dort Deine Exception herkommen.