der Fehler tritt quasi im Hintergrund auf: Einer der ESI-Calls produziert einen Fehler und die aufrufende Seite meldet dann “ESI-Call fehlgeschlagen”. Die eigentliche Fehlermeldung ist irgendwas anderes - müsste aber auch in deinen Logs sehen. Gibt es da drumherum noch Exceptions im Log?
der Fehler tritt quasi im Hintergrund auf: Einer der ESI-Calls produziert einen Fehler und die aufrufende Seite meldet dann „ESI-Call fehlgeschlagen“. Die eigentliche Fehlermeldung ist irgendwas anderes - müsste aber auch in deinen Logs sehen. Gibt es da drumherum noch Exceptions im Log?
Hi Daniel.
Leider gibt es in der Log nicht mehr. Der Fehler tritt in der Regel täglich auf und nach dem leeren der Cache läuft er wieder bis zum nächsten Fehler. Ich habe den Verdacht, dass das auftritt, seit wir die Seite überall auf HTTPS umgestellt haben. Aber sicher kann ich das nicht sagen.
Hier ein Log auszug über 3 Tage
[19-Jun-2016 12:37:47 Europe/Berlin] PHP Fatal error: Uncaught exception 'RuntimeException' with message 'Error when rendering "https://www.XXX.de/?action=shopMenu&controller=index&module=widgets" (Status code is 503).' in /home/XXX/public_html/vendor/symfony/http-kernel/HttpCache/Esi.php:282
Stack trace:
#0 /home/XXX/public_html/var/cache/production_201604081130/html/en/37/4f/a6f8f295583e7a9b0c6ff468973eff599f1e0334321b1d7c17a65f8ed924(62): Symfony\Component\HttpKernel\HttpCache\Esi->handle(Object(Shopware\Components\HttpCache\AppCache), '/?module=widget...', '', false)
#1 /home/XXX/public_html/vendor/symfony/http-kernel/HttpCache/HttpCache.php(646): include('/home/XXX/...')
#2 /home/XXX/public_html/vendor/symfony/http-kernel/HttpCache/HttpCache.php(216): Symfony\Component\HttpKernel\HttpCache\HttpCache->restoreResponseBody(Object(Symfony\Component\HttpFoundation\Request), Object(Symfony\Component\HttpFoundation\Response))
#3 /home/XXX/public_html/engine/Shopware/Components/HttpCache/AppCache.php(114): Symfony\Co in /home/XXX/public_html/vendor/symfony/http-kernel/HttpCache/Esi.php on line 282
[20-Jun-2016 00:38:47 Europe/Berlin] PHP Fatal error: Uncaught exception 'RuntimeException' with message 'Error when rendering "https://www.XXX.de/?controller=compare&module=widgets" (Status code is 503).' in /home/XXX/public_html/vendor/symfony/http-kernel/HttpCache/Esi.php:282
Stack trace:
#0 /home/XXX/public_html/var/cache/production_201604081130/html/en/d2/a4/c865e0644947bc43982db95b11e374785b15c6ef5d52acbb5ea60a6cba3f(65): Symfony\Component\HttpKernel\HttpCache\Esi->handle(Object(Shopware\Components\HttpCache\AppCache), '/?module=widget...', '', false)
#1 /home/XXX/public_html/vendor/symfony/http-kernel/HttpCache/HttpCache.php(646): include('/home/XXX/...')
#2 /home/XXX/public_html/vendor/symfony/http-kernel/HttpCache/HttpCache.php(216): Symfony\Component\HttpKernel\HttpCache\HttpCache->restoreResponseBody(Object(Symfony\Component\HttpFoundation\Request), Object(Symfony\Component\HttpFoundation\Response))
#3 /home/XXX/public_html/engine/Shopware/Components/HttpCache/AppCache.php(114): Symfony\Component\HttpKe in /home/XXX/public_html/vendor/symfony/http-kernel/HttpCache/Esi.php on line 282
[21-Jun-2016 17:28:47 Europe/Berlin] PHP Fatal error: Uncaught exception 'RuntimeException' with message 'Error when rendering "https://www.XXX.de/?action=info&controller=checkout&module=widgets" (Status code is 503).' in /home/XXX/public_html/vendor/symfony/http-kernel/HttpCache/Esi.php:282
Stack trace:
#0 /home/XXX/public_html/var/cache/production_201604081130/html/en/39/ac/aa8f0abb04982e7d2ee50549d2eeaa93671ce0e15046ef797eaa69b533b6(111): Symfony\Component\HttpKernel\HttpCache\Esi->handle(Object(Shopware\Components\HttpCache\AppCache), '/?module=widget...', '', false)
#1 /home/XXX/public_html/vendor/symfony/http-kernel/HttpCache/HttpCache.php(646): include('/home/XXX/...')
#2 /home/XXX/public_html/vendor/symfony/http-kernel/HttpCache/HttpCache.php(216): Symfony\Component\HttpKernel\HttpCache\HttpCache->restoreResponseBody(Object(Symfony\Component\HttpFoundation\Request), Object(Symfony\Component\HttpFoundation\Response))
#3 /home/XXX/public_html/engine/Shopware/Components/HttpCache/AppCache.php(114): Symfony\Co in /home/XXX/public_html/vendor/symfony/http-kernel/HttpCache/Esi.php on line 282
das kann dir bei bestimmten Konstellationen des verwendeten Hostings passieren. Wie lange ist denn der Zeitraum zwischen dem Leeren des Caches und dem ersten Auftreten des Fehlers bei wievielen Zugriffen?
das kann dir bei bestimmten Konstellationen des verwendeten Hostings passieren. Wie lange ist denn der Zeitraum zwischen dem Leeren des Caches und dem ersten Auftreten des Fehlers bei wievielen Zugriffen?
Die Seite hat nur um die 50 Aufrufe am Tag. Das Problem trat anfangs alle paar Tage auf und nun fast täglich. Der zeitraum zwischen leeren der Cache und auftreten des Fehlers variiert zwischen einem und mehreren Tagen.
Welche Faktoren am Hosting sollen denn einen Einfluß haben?
Mit PHP 5.6.21+ gibt es ja das Problem mit falsch serialisierten Daten in der Config. Wäre das ein Kandidat? Wir haben zwar die SQL Queries ausgeführt, die die fehlerhaften Einträge korrigieren sollten, aber vielleicht gibt es in der Cache Konfiguration doch noch ein Problem
das kann dir bei bestimmten Konstellationen des verwendeten Hostings passieren. Wie lange ist denn der Zeitraum zwischen dem Leeren des Caches und dem ersten Auftreten des Fehlers bei wievielen Zugriffen?
Die Seite hat nur um die 50 Aufrufe am Tag. Das Problem trat anfangs alle paar Tage auf und nun fast täglich. Der zeitraum zwischen leeren der Cache und auftreten des Fehlers variiert zwischen einem und mehreren Tagen.
Welche Faktoren am Hosting sollen denn einen Einfluß haben?
Mit PHP 5.6.21+ gibt es ja das Problem mit falsch serialisierten Daten in der Config. Wäre das ein Kandidat? Wir haben zwar die SQL Queries ausgeführt, die die fehlerhaften Einträge korrigieren sollten, aber vielleicht gibt es in der Cache Konfiguration doch noch ein Problem
Es gibt unterschiedliche Stellen im Hosting, die Probleme im Cache-Management mit den ESI-Calls erzeugen können. Es kann das Dateisystem sein oder die zur Verfügung stehenden Ressourcen. Ich kenne das Problem von Kunden, die Shopware auf Hosting-Paketen betreiben, bei dem versucht wird noch das letzte Quentchen Leistung aus einem Webserver zu quetschen. Dann kommen sich die unterschiedlichen technischen Lösungen in die Quere, wie genau kann man nicht immer nachvollziehen bzw. ist dann auch uninteressant für mich. Shopware benötigt eine gewisse Grundausstattung an Hardware/Software-Ressourcen, aber bei den genannten Zugriffen eigentlich auch nur eine „normale“ LAMPP-Installation um ordentlich performant zu laufen.
Eine Lösung in Eurem Fall könnte das häufigere manuelle oder Cronjob-gesteuerte Löschen des HTTP-Proxy-Caches sein. Vor allem, weil keine weiteren Fehler in den Logs stehen. Es ist natürlich immer schwierig, dies zu beurteilen, wenn man das System nicht kennt.