Unvorhersehbare HTTP 500 Errors während Arbeit im Backend

Hallo zusammen,

ich muss mich vorab als Mediengestalter und damit als Nicht-Programmierer mit gefährlichem Halbwissen outen. :wink:

Ich habe für einen Kunden in den letzten Monaten einen Shop mit der Community Edition aufgebaut, der seit Vorgestern online ist. Der Shop wurde im gleichen Verzeichnis auf einem Managed Hosting Server bei Domainfactory entwickelt, in dem er jetzt auch live läuft.

Prinzipiell läuft er auch ohne Probleme, allerdings habe ich seit kurz vor dem Live-Gehen im Backend das Problem, dass ich während der Arbeit in nicht reproduzierbaren unregelmäßigen Abständen mit einem Error 500 rausfliege. Ich habe mich daraufhin erstmal beim Hoster erkundigt, ob irgendwelche Serverprobleme existieren. Dies wurde aber verneint und mir wurde mitgeteilt, dass im Server Log aber erkennbar wäre, dass irgendwelche Shopware Skripte die maximale CPU Laufzeit des Tarifs überschreiten. Außerdem wurde ich gefragt, ob ich irgendwelche aufwendigen Dinge im Backend durchführen würde. Das war und ist aber nicht der Fall. Ich habe lediglich ein paar Preise angepasst, ein paar Formatierungs- und Schreibfehler in Produkttexten geändert usw.

Im CGI Debugger von Domainfactory konnte ich dann feststellen, dass Zend Loader und Zend API ständig Errors verursacht haben und dachte schon, dass ich durch deaktivieren dieser Komponenten in der PHP.ini das Problem gelöst hätte. Leider war es das nicht, die Fehler treten weiter auf.

Daraufhin habe ich dann die Shopware Logs angesehen und die Logs der letzten Tage mit denen aus dem Dezember verglichen. Im Dezember gab es hin und wieder mal einen Eintrag, dass eine Bild URL nicht stimmt, seit dem 2.01. gibt es aber täglich zig Einträge wie den folgenden:

[2018-01-04 11:17:11] core.ERROR: exception 'RuntimeException' with message 'Could not connect to database. Message from SQL Server: SQLSTATE[HY000] [2002] Cannot assign requested address' in /kunden/xyz/webseiten/shopware/engine/Shopware/Components/DependencyInjection/Bridge/Db.php:78 Stack trace: 
#0 /kunden/xyz/webseiten/shopware/engine/Shopware/Plugins/Default/Backend/Auth/Bootstrap.php(499): Shopware\Components\DependencyInjection\Bridge\Db::createPDO(Array) 
#1 /kunden/xyz/webseiten/shopware/engine/Shopware/Plugins/Default/Backend/Auth/Bootstrap.php(368): Shopware_Plugins_Backend_Auth_Bootstrap->createSaveHandler(Object(ShopwareProductionda39a3ee5e6b4b0d3255bfef95601890afd80709ProjectContainer)) 
#2 /kunden/xyz/webseiten/shopware/engine/Library/Enlight/Event/Handler/Plugin.php(149): Shopware_Plugins_Backend_Auth_Bootstrap->onInitResourceBackendSession(Object(Enlight_Event_EventArgs)) 
#3 /kunden/xyz/webseiten/shopware/engine/Library/Enlight/Event/EventManager.php(251): Enlight_Event_Handler_Plugin->execute(Object(Enlight_Event_EventArgs)) 
#4 /kunden/xyz/webseiten/shopware/engine/Shopware/Components/DependencyInjection/Container.php(209): Enlight_Event_EventManager->notifyUntil('Enlight_Bootstr...', Array) 
#5 /kunden/xyz/webseiten/shopware/engine/Shopware/Components/DependencyInjection/Container.php(167): Shopware\Components\DependencyInjection\Container->doLoad('backendsession') 
#6 /kunden/xyz/webseiten/shopware/engine/Shopware/Plugins/Default/Backend/Auth/Bootstrap.php(388): Shopware\Components\DependencyInjection\Container->load('BackendSession') 
#7 /kunden/xyz/webseiten/shopware/engine/Library/Enlight/Event/Handler/Plugin.php(149): Shopware_Plugins_Backend_Auth_Bootstrap->onInitResourceAuth(Object(Enlight_Event_EventArgs)) 
#8 /kunden/xyz/webseiten/shopware/engine/Library/Enlight/Event/EventManager.php(251): Enlight_Event_Handler_Plugin->execute(Object(Enlight_Event_EventArgs)) 
#9 /kunden/xyz/webseiten/shopware/engine/Shopware/Components/DependencyInjection/Container.php(209): Enlight_Event_EventManager->notifyUntil('Enlight_Bootstr...', Array) 
#10 /kunden/xyz/webseiten/shopware/engine/Shopware/Components/DependencyInjection/Container.php(146): Shopware\Components\DependencyInjection\Container->doLoad('auth', 1) 
#11 /kunden/xyz/webseiten/shopware/engine/Shopware/Plugins/Default/Backend/Auth/Bootstrap.php(226): Shopware\Components\DependencyInjection\Container->get('Auth') 
#12 /kunden/xyz/webseiten/shopware/engine/Shopware/Plugins/Default/Backend/Auth/Bootstrap.php(207): Shopware_Plugins_Backend_Auth_Bootstrap->checkAuth() 
#13 /kunden/xyz/webseiten/shopware/engine/Library/Enlight/Event/Handler/Plugin.php(149): Shopware_Plugins_Backend_Auth_Bootstrap->onPreDispatchBackend(Object(Enlight_Controller_ActionEventArgs)) 
#14 /kunden/xyz/webseiten/shopware/engine/Library/Enlight/Event/EventManager.php(214): Enlight_Event_Handler_Plugin->execute(Object(Enlight_Controller_ActionEventArgs)) 
#15 /kunden/xyz/webseiten/shopware/engine/Library/Enlight/Controller/Action.php(138): Enlight_Event_EventManager->notify('Enlight_Control...', Object(Enlight_Controller_ActionEventArgs)) 
#16 /kunden/xyz/webseiten/shopware/engine/Library/Enlight/Controller/Dispatcher/Default.php(530): Enlight_Controller_Action->dispatch('getPluginInform...') 
#17 /kunden/xyz/webseiten/shopware/engine/Library/Enlight/Controller/Front.php(223): Enlight_Controller_Dispatcher_Default->dispatch(Object(Enlight_Controller_Request_RequestHttp), Object(Enlight_Controller_Response_ResponseHttp)) 
#18 /kunden/xyz/webseiten/shopware/engine/Shopware/Kernel.php(189): Enlight_Controller_Front->dispatch() 
#19 /kunden/xyz/webseiten/shopware/vendor/symfony/http-kernel/HttpCache/HttpCache.php(491): Shopware\Kernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) 
#20 /kunden/xyz/webseiten/shopware/engine/Shopware/Components/HttpCache/AppCache.php(268): Symfony\Component\HttpKernel\HttpCache\HttpCache->forward(Object(Symfony\Component\HttpFoundation\Request), true, NULL) 
#21 /kunden/xyz/webseiten/shopware/vendor/symfony/http-kernel/HttpCache/HttpCache.php(258): Shopware\Components\HttpCache\AppCache->forward(Object(Symfony\Component\HttpFoundation\Request), true) 
#22 /kunden/xyz/webseiten/shopware/engine/Shopware/Components/HttpCache/AppCache.php(105): Symfony\Component\HttpKernel\HttpCache\HttpCache->pass(Object(Symfony\Component\HttpFoundation\Request), true) 
#23 /kunden/xyz/webseiten/shopware/shopware.php(118): Shopware\Components\HttpCache\AppCache->handle(Object(Symfony\Component\HttpFoundation\Request)) 
#24 {main} [] {"uid":"8566652"}

Habt Ihr eine Idee, woher diese Einträge kommen können? - Ist da evtl. doch ein Problem auf Hoster-Seite oder stehe ich komplett auf dem Schlauch?

Wenn ich die ersten Zeilen richtig verstehe, gibt es Probleme mit dem Datenbank Zugriff. Im entsprechenden „Slow Query Log“ im Debugger beim Hoster sind allerdings keinerlei Einträge vorhanden. Und ich hatte während der kompletten Aufbauphase des Shops keinerlei Probleme dieser Art. Bei meinen Tests vor Weihnachten lief alles rund, ohne 500er Errors oder sonstige Auffälligkeiten.

Über Antworten würde ich mich sehr freuen.

Viele Grüße und vielen Dank im Voraus
Christoph

Das scheint ein Limit bei MySQL zu sein. Ist das ein Hosting-Paket wo DF sagt, dass Shopware ohne Probleme drauf laufen würde?

Hallo NextMike,

vielen Dank für Deine Antwort!

Die empfehlen für Shopware einen Managed Server und der Kunde hat bisher “nur” den Managed Hosting Ultimate Tarif. Insofern ist es möglich, dass das daran liegt. 

Allerdings hat während der Entwicklung wie gesagt alles ohne jegliche derartige Probleme funktioniert und ich habe im Dezember ziemlich intensiv getestet ohne ein einziges Mal ein solches Problem zu haben.

Von daher tue ich mir etwas schwer, dem Kunden zu empfehlen, mal eben von einem 40 Euro Tarif in einen 100 Euro Tarif zu wechseln (soviel kostet der kleinste Managed Server Tarif bei DF), zumal der Shop eher überschaubaren Umsatz generiert und sich auch die Anzahl der Bestellungen in Grenzen hält.

Viele Grüße
Christoph

Na ja, bei Profihost und Co. kriegt man schon für 30 EUR einen Server der was aushält. Ich hatte vermutet Du bist mit einem 5 EUR Hosting unterwegs.

Vielleicht laufen doch irgendwelche Plugins Amok? Oder Deine Umgebung hat ein Problem.

Hier ist man vom Hosting her auf der sicheren Seite: https://de.shopware.com/Partner/list/type/hosting

Hast Du so viel Traffic?

Ich würde dir ebenfalls raten zu wechseln, aber nicht unbedingt zu einem aus der verlinkten Liste. Kannst Du machen, aber nimm nicht die billigen/preiswerten Angebote von denen. Es hängt etwas von dem Anforderungsprofil ab. 

Die Fehlermeldung im Shopware-Log ist nicht wirklich aussagekräftig. Du weißt eigentlich nur, dass SQL-Verbindungen zu zahlreich aufgebaut werden und Mysql sich weigert neue aufzubauen. In der Regel ist das ein Fehler im Skript, bei dem Hostingpaket eher unwahrscheinlich. Plugins und Serverzugriffe solltest Du dir trotzdem einmal anschauen. Du musst auf keinen Fall einen dedizierten Server nehmen, wenn Du nicht per Plugin etwas sehr stark an Shopware verändert hast.

Grundsätzlich fährst Du mit einem managed Server (vServer) besser bei dem Du das Recht hast, die Konfigurationen anzupassen als mit den Shared Hosting Angeboten. Schick mir eine PM, wenn Du eine alternative Adresse benötigst.

Viele Grüße

Soweit ich es anhand des Access Logs beurteilen kann, waren bisher heute maximal 10 Leute im Shop, die sich zum Großteil ein bis zwei Produkte angeschaut haben. Alle anderen Zugriffe sind von mir über das Backend und da geht’s echt um marginale Dinge, wie oben beschrieben. Daher sehe ich auch nicht, warum jetzt die Probleme auftreten, die es vorher nie gab.

Ich habe die Fehlermeldung und auch den Pfad zum Shopware Error Log jetzt nochmal an DF geschickt, denn eigentlich bin ich mit denen bisher immer sehr zufrieden gewesen und der Support ist im Normalfall wirklich sehr fit und bemüht. Und eigentlich unterstelle ich denen auch nicht, dass sie dem Kunden jetzt unbedingt auf ein teureres Paket andrehen wollen. Aber wenn die es nicht in den Griff bekommen, werde ich dem Kunden wohl empfehlen müssen, zu einem anderen Hoster zu wechseln.

Vielen Dank auch für den Link! Ich hoffe zwar noch, dass wir ihn nicht brauchen werden, aber im Zweifelsfall werde ich dann dort nach Alternativen schauen.

Viele Grüße
Christoph

Hallo hth,

vielen Dank auch für Deine Antwort!

Eigentlich war ich froh, dass der Shop jetzt endlich soweit fertig und online ist. Mit einem kompletten Umzug inkl. Einrichtung usw. wäre ich aktuell komplett bedient, da ich parallel Abgaben für einen anderen Kunden habe. :confused:

Das Anforderungsprofil ist prinzipiell nicht sonderlich hoch. Der Kunde hat mit Produktvarianten ca. 100 Produkte im Shop, wir verwenden ein leicht angepasste Variante des Standard Responsive Templates und an zusätzlichen PlugIns laufen eigentlich nur Paypal und die Schnittstelle zur Orgamax WaWi. Wie oben bereits beschrieben hat der Kunde saisonabhängig zwischen 3 und 20 Bestellungen täglich, nach einem Newsletter vielleicht auch mal 40.

Auch wenn ich mich wiederhole, erstaunt es mich total, dass diese Probleme so plötzlich auftreten, obwohl ich nichts verändert habe. Habe am 20.12.2017 noch wie ein Wilder getestet (und dabei garantiert mehr Zugriffe generiert als es aktuell durch Kunden welche gibt), dann Weihnachtspause gemacht und jetzt am 2.01.2018 ständig Probleme gehabt, dass das Backend mich rausgeschmissen hat.

Ich hoffe jetzt drauf, dass die DF Leute sich das vielleicht doch nochmal genauer anschauen und das Problem finden. Falls nicht, melde ich mich gerne bei Dir und bin für jeden Tipp bzgl. Alternativen dankbar. Allerdings bin ich wie gesagt technisch nicht sonderlich bewandert und weiß nicht, ob ein Managed Server mich im Zweifelsfall überfordert. :wink:

Viele Grüße und vielen Dank!
Christoph

Hallo,

mal ne dumme Frage: Verwendest Du und Dein Kunde denselben BE-User? Dann werft ihr euch gegenseitig raus

Hallo drakon,

vielen Dank für die Nachfrage und für dumm halte ich sie nicht, da das von Dir beschriebene Szenario vermutlich gar nicht so unwahrscheinlich ist. Das tun wir aber nicht.

Das würde ja „nur“ zu einer Abmeldung führen mit der Folge, dass danach die Login Seite des Backends angezeigt wird. Ich bekomme in Chrome aber immer diese hübsche graue Error 500 Seite, wenn ich rausfliege.

Habe von DF vorhin auch eine Nachricht bekommen, dass sie mein Anliegen nochmal in einer andere Abteilung weitergegeben haben. Mal abwarten, ob sie uns jetzt „auf Halde“ legen oder sich eingehender mit der Problematik beschäftigen.

Viele Grüße
Christoph

Gehe auch davon aus das es am Hosting liegt, SW ist ein recoursen fressendes Monster. Zu dem Preis kannst du auch zu einem SW Partner gehen bei dem du sicher sein kannst das dein Shop läuft. Frage mal bei AIXPRO an, vielleicht bekommst du ja ein paar Tage einen Server zum testen.  Wink  Sind dort über 2 Jahre und auch bei den billigen Hosting Servern laufen die SW Shops ohne Probleme.

Lg

Wie gesagt, bis 20.12. lief alles ohne irgendwelche Errors und ich habe seitdem nichts verändert und auch die Zugriffe auf den Shop sind seitdem nicht nennenswert gestiegen, zumal ich die Probleme dann am 2.01. schon hatte, als der Shop noch in der Test-Subdomain lief und noch gar nicht live war. Zu dieser Zeit habe definitiv nur ich darauf zugegriffen und da gab es diese Lastspitzen auf einmal, die es vorher nicht gab.

Ich warte jetzt ab, ob DF das Problem im aktuellen Tarif beseitigen kann. Ansonsten muss ich dem Kunden wohl raten, in den sauren Apfel zu beißen und zu einem anderen Hoster umzuziehen.

Viele Grüße
Christoph

@toph schrieb:

Wie gesagt, bis 20.12. lief alles ohne irgendwelche Errors und ich habe seitdem nichts verändert und auch die Zugriffe auf den Shop sind seitdem nicht nennenswert gestiegen, zumal ich die Probleme dann am 2.01. schon hatte, als der Shop noch in der Test-Subdomain lief und noch gar nicht live war. Zu dieser Zeit habe definitiv nur ich darauf zugegriffen und da gab es diese Lastspitzen auf einmal, die es vorher nicht gab.

Ich warte jetzt ab, ob DF das Problem im aktuellen Tarif beseitigen kann. Ansonsten muss ich dem Kunden wohl raten, in den sauren Apfel zu beißen und zu einem anderen Hoster umzuziehen.

Viele Grüße
Christoph

Du darfst aber nicht vergessen du hast nur ein Hosting, es muss nicht umbedingt an dir liegen, denn wenn am selben Server ein anderer Kunde es übertreibt, leiden alle Kunden darunter welche am selben Server liegen. 

Daher rate ich und auch viele andere hier, bei einem Shop mit den man Geld verdienen will zu einen vServer oder noch besser einen root zu greifen. Am Anfang tut es aber auch ein vServer wo nicht so viele Kunden drauf liegen und in der Regel problemlos laufen.

Lg

Ja, die Möglichkeit sehe ich auch. Allerdings hat der Kunde den leistungsstärksten Managed Hosting Tarif mit „6 Sterne Performance“, der auf der DF Website u.a. mit „für große Online-Shops“ beworben wird.

Laut Beschreibung hat man in diesem Tarif 256 MB RAM und 120 CPU Sekunden (Skriptlaufzeit pro Aufruf bis 300 Sekunden). Mir sagen diese Werte leider nicht viel, aber vielleicht kann ja von Euch jemand beurteilen, ob das wirklich zu schwachbrüstig ist.

Früher hatten die auch mal dabei stehen, wieviele Kunden bei welchem Tarif maximal auf einem Server liegen. Das konnte ich aber eben nicht mehr finden.

Viele Grüße und vielen Dank
Christoph

Wenn viele andere mit am Server sind und die dann auch noch reboots auslösen können dann wäre das vermutlich auch so ein Grund auf einen eigenen Server umzusteigen.

@toph schrieb:

Ja, die Möglichkeit sehe ich auch. Allerdings hat der Kunde den leistungsstärksten Managed Hosting Tarif mit “6 Sterne Performance”, der auf der DF Website u.a. mit “für große Online-Shops” beworben wird.

Laut Beschreibung hat man in diesem Tarif 256 MB RAM und 120 CPU Sekunden (Skriptlaufzeit pro Aufruf bis 300 Sekunden). Mir sagen diese Werte leider nicht viel, aber vielleicht kann ja von Euch jemand beurteilen, ob das wirklich zu schwachbrüstig ist.

Früher hatten die auch mal dabei stehen, wieviele Kunden bei welchem Tarif maximal auf einem Server liegen. Das konnte ich aber eben nicht mehr finden.

Viele Grüße und vielen Dank
Christoph

Oft liegen 100 Kunden und mehr auf einen Server.  Wink Bei einem vServer oft nur 10, hängt aber vom Anbieter ab.

Wir hatten genau das selbe Problem wie du, 1 Jahr lang lief alles einwandfrei, und dann täglich Probleme im Backend. Frown Nach unserer Beschwerde wurde zwar der verursacher ermittelt und gesperrt, aber es dauerte nicht lange kam schon der nächste Neukunde der meinte am Server die Sau rauslassen zu müssen. Frown Das Problem hatten nicht nur wir, sondern alle Kunden auf diesem Server. Gibt diesbezüglich sogar einen Thread von mir hier im Forum.

Also haben wir auf einen vServer gewechselt, danach war endlich Ruhe. In der Zwischenzeit haben wir einen root und sind damit sehr zufrieden.

 

@toph schrieb:

Ja, die Möglichkeit sehe ich auch. Allerdings hat der Kunde den leistungsstärksten Managed Hosting Tarif mit „6 Sterne Performance“, der auf der DF Website u.a. mit „für große Online-Shops“ beworben wird.

Laut Beschreibung hat man in diesem Tarif 256 MB RAM und 120 CPU Sekunden (Skriptlaufzeit pro Aufruf bis 300 Sekunden). Mir sagen diese Werte leider nicht viel, aber vielleicht kann ja von Euch jemand beurteilen, ob das wirklich zu schwachbrüstig ist.

Es ist halt trotzdem nur ein Shared Hosting, und das hat gewisse Nachteile: http://community.shopware.com/_detail_2002.html#Shared_Hosting

Wenn Du diese Nachteile ausschließen möchtest, solltest Du ggf. einmal einen vServer oder Server testen.

Timme Hosting - schnelles nginx-Hosting

www.timmehosting.de

Am Hosterpaket von DF kann es eigentlich nicht liegen. Wir glauben nicht, daß immer ein eigener Server für einen kleinen Shop nötig ist. Bei Domain Factory haben wir sogar 2 Shops unter einem Managed Hosting Ultimate Paket laufen. Alles läuft bestens, selbst ohne APCu und Zend OPcache.  In einem Shop haben wir ca 500 Artikel die alle Custom Products Varianten haben. Und seit über 2 Jahren laufen die Shops schon. Im Vorfeld, aber auch jetzt noch, haben wir unzählige Hoster und Shopware Hosting Pakete getestet, und Sorry, selbst bei Aixpro und Timme mit  NGINX oder auch mit LiteSpeed läuft unser Shop nicht spürbar schneller bzw. besser. Jeder Hoster hat seine Vor- und Nachteile. Da hilft halt nur testen… 

 

 

Hallo Zocas,
es freut mich, dass bei Euch bei DF alles läuft, und Du kannst mir glauben, dass es mir mehr als recht wäre, wenn bei besagtem Kunden auch alles laufen würde. Ich war mit deren Support bisher immer sehr zufrieden und Probleme wurden immer schnell gelöst. Daher habe ich in den letzten Jahren auch allen Kunden DF empfohlen (wobei die meisten keine Shops laufen haben).

Im aktuellen Fall verhält es sich aber leider anders und das Problem besteht nach wie vor. Die Aussage von DF ist, dass der Shop mehr Performance und daher ein Upgrade auf einen eigenen Server bräuchte. Dass bis Dezember auf diesem Server und mit unveränderter Konfiguration alles problemlos lief, führte nach mehrfachem Nachfragen zu der Antwort, dass es sein könne, dass ein anderer Kunde auf dem gleichen Server soviel Last erzeugt, dass das Paket meines Kunden mitbetroffen ist. Dies sei aber auch durch einen Umzug meines Kunden auf einen anderen Server nicht dauerhaft auszuschließen. - Für mich nachvollziehbar, aber trotzdem wenig befriedigend.

Daher werden wir jetzt wohl den Aufwand auf uns nehmen und komplett zu einem auf Shopware spezialisierten Anbieter umziehen.