Neu Weiterleitungen 504 Timeout

[lotex24.systems]

Hallo JTLer,

ich habe mich heute mal mit der Einstellung Weiterleitungen unserer Shops im Admin beschäftigt. Da ich das nicht so regelmäßig tue, vielleicht auch ein Fehler, ist mir auf unseren zwei Maschinen etwas aufgefallen. DIE PROZESSE KACKEN AB und die Domain steht, sobald im Backend die ZielURL geprüft wird.

Ich will jetzt nicht die ganze Konfiguration der Maschinen schreiben, doch passiert dies sowohl FastCGI per Apache, FPM Apache, FPM Ningx. PHP 7.2.12 -> memory_limit 256 Ausführung für das Script 120s.

Ich schraube auch schon an der MySQL bzw. MariaDB.

Will jetzt nicht über ServerConfig diskutieren, dass würde dem normalen Nutzer der ein Hostingpaket hat nicht viel nützen. Hat jemand ähnliche Probleme?

VG Jan
PS: Shop 4.06.9

 

[martinwolf]

Hatte das Problem bei einer Kundin ebenfalls, wodurch der gesamte Shop zu Stoßzeiten (meist Sonntag Abend) einfach verreckt ist. Da ich Aufgrund meiner mangelnden Kenntnisse was Server Administration und Konfiguration keine Lösung zur Hand hatte, habe ich die Weiterleitungen im Core komplett abgedreht. Seitdem, keinerlei Ausfälle mehr.

 

[MichaelH]

Ich kann das auch bestätigen, bei mir das gleiche Problem seit Umstellung auf Shop4.

Du kannst auch mal die Sortierung ändern z.B. nach "Anzahl der Aufrufe".
Der Shop steht, das Backend reagiert nicht mehr.
Soweit ich mich erinnern kann 90-120 Sekunden, jetzt testen möchte ich es nicht, denn der Shop steht dann.

Mein SP ist am Schauen, aber in 3 Monaten bislang kein Ergebnis.

Da der Shop4 schon 2 Jahre alt ist und wir erst kürzlich umgestellt haben, dachte ich es muss an uns liegen. daher DANKE für eure Beiträge.

Ich vermute hier doch eher ein JTL-Problem im Zusammenhang mit irgendetwas vom "Server".

Im Hintergrund werden zur URL-Prüfung unzählige Prozesse angestossen, das ist OK so, aber die Prozesse selbst haben ein Problem oder verursachen das Problem.

Wenn wir nun mind. schon 3 sind, nimmt sich JTL vielleicht dem Problem an ?
Ich werde meinen SP informieren, damit wir ggf. Daten und Infos austauschen können.

OK so ? Schreibt mir bitte eine PN wenn ihr wollt.

 

[lotex24.systems]

Danke @martinwolf und @MichaelH für die Rückmeldung.

Ich denke das dieses Problem nur auftaucht, wenn zum ersten mal viele Weiterleitungen auf die ZielUrl geprüft werden müssen und dann auch noch den Filter auf 50 oder mehr Einträge gestellt ist. Wenn ich das richtig deute, wird bei der geprüften Weiterleitung ein Flag gesetzt oder wird gecacht. Aufgefallen ist mir dies beim navigieren in der Seite zurück, wo sofort die Weiterleitung als True oder False markiert wurde.

Die Weiterleitung bzw. die Prozesse auf der Maschine für das jeweilige Paket funktioniert nun bei uns soweit wieder flüssig. Immer wenn die Prozesse abgeschmiert sind, haben wir den Webserver (Apache, Ningx) neugestartet und ins Backend neu eingeloggt. Alle fehlerhaften Weiterleitungen dann von Hand gelöscht bzw. alle Weiterleitungen ohne Eintrag.

VG Jan

 

[MichaelH]

Den Webserver neu starten, das ist für uns keine Option.
Manuell löschen auch nicht bei 8688 Weiterleitungen.

Blättern mit 10 Einträgen pro Seite geht, wenn die URLs leer sind, sobald 3, 4 befüllt sind geht es noch, aber ab Seite 6 und alle mit URL ist Ende.

Und eine Sortierung absteigend nach Häufigkeit ist auch ein automatisches Ende.

Kurz gesagt: Sobald eine Seite mit 10 Einträgen und alle mit URL sind, steht der Shop.

Und manche Prozesse werden nie fertig, so wie es aussieht, siehe Bild.
"Live" testen ist nicht gut, denn der Shop steht und die Kunden sind weg auch um 23:11 Uhr.

 

[lotex24.systems]

genau das habe ich auch gehabt. Ich habe noch einen Shop den ich von 3.20 auf 4.0.6.xx hochziehen muss (war auch bei einem frischen 4.0.xx Shop das Problem), dann schalte ich die Logs mal mit.

Was etwas gebracht hat, waren drei Zeilen in der my.conf :

innodb_log_buffer_size=6M
innodb_buffer_pool_size=1024M
innodb_thread_concurrency=8

Hat zwei drei mal gut funktioniert, doch hatte ich Last auf der Maschine, wars dann auch schon wieder vorbei. JTL sollte sich das wirklich mal annehmen ...

Als mir das bei dem ersten Shop aufgefallen ist, habe ich die anderen in der Nacht gemacht, wo eher weniger bei uns bestellt wird.

Verstehe Deine Bedenken.

VG Jan

PS: Wawi 099922 und Shop 4 das funktioniert ? Deine Signatur ...
PSS: @JTL eventuell die Seitennavigation auch am Ende der Liste einbauen???

 

[MichaelH]

PS: Ja das geht, ich upgrade gerade jetzt über Mittag auf 1.3.20, bringt zwar keine Vorteile, aber dann sind wir auch mal wieder up-to-date. Man kann ja nicht ewig VW Golf I fahren, auch wenn das Ding alles kann was man braucht.

 

[css-umsetzung]

Hallo @JTL

ich habe einen Kunden mit einem Managed Server bei Hetzner.
Hetzner sagt die Programmierung vom Shop ist schuld das die Server crashen wenn man sich die Weiterleitungen im Backend zum bearbeiten aufruft.

Ich selbst habe auch einige Kunden mit Servern die alles locker wegstecken sollten, aber auch die crashen gerne wenn ein Shopbesitzer in die Weiterleitungen geht, ich musste hier viele Werte extrem hoch einstellen damit die Server nicht crashen.

 

[Shopsitters]

Selbes Problem auch bei uns

Gesendet von meinem SM-G960F mit Tapatalk

 

[MBesancon]

Wir haben da auch das ein oder andere Beispiel

 

[JulianG]

Hallo zusammen,

bis 4.06 könnte das Problem zusammenhängen mit der Nutzung von FPM. Mit FastCGI sollte zumindest das Problem, welches ich im Kopf habe, nicht auftreten. Man kann die Überprüfung der Weiterleitungs-Erreichbarkeit deaktivieren, in dem ihr folgende Funktion entfernt/ausklammert: https://gitlab.jtl-software.de/jtlshop/shop4/blob/v4.05.9/admin/templates/bootstrap/redirect.tpl#L26
{*foreach $oRedirect_arr as $oRedirect}
check_url({$oRedirect->kRedirect}, '{$oRedirect->cToUrl}');
{/foreach*}

Mit 4.06 sollte das Problem aber nicht mehr auftreten. Also @lotex24.systems bitte einmal prüfen, ob du eventuell modifizierte Dateien hast (System->Wartung->Status). Da du aber auch schon mit FastCGI getestet hast, müssen wir uns das ggf. genauer ansehen. Falls möglich erstelle bitte ein Ticket für JTL- Shop über unseren Kundencenter und verweise auf diesen Thread. Wenn du kein Ticket erstellen kannst, starte bitte eine private Unterhaltung mit mir.

 

[css-umsetzung]

Also das Problem besteht auch in einem 4.06er
Und ja, beim fpm Modul habe ich keine chance etwas dagegen zu tun, ich hatte auch die Anzahl der Apachen hochgeschraubt, auch das half nicht.

Wenn ich beim fcgi Modul alle Werte hochschraube crashed das nicht aber das Errorlog ist voll mit Einträgen, Tatsache ist aber das es viel besser wäre den Shop mit dem fpm laufen zu lassen und nicht jeder kann das beeinflussen.

 

[JulianG]

In 4.06 könnt ihr es auch auskommentieren: https://gitlab.jtl-software.de/jtls...06/admin/templates/bootstrap/redirect.tpl#L22

zu: //checkUrl({$oRedirect->kRedirect}, true);

Die Überprüfung bei Seitenaufruf findet dann nicht mehr statt. Wenn ihr ein Feld bearbeitet habt (auch nur kurz rein-raus klicken) wird es weiterhin geprüft. Einzelne Anfragen sollten aber kein Problem sein. Das Problem wird schlimmer, je mehr Weiterleitungen ihr auf einer Seite anzeigen lasst.

Wir haben das Entwickerticket noch einmal geöffnet und haben vermutlich von einem von euch auch ein offenes Ticket dazu. Wir schauen uns das also noch einmal an. Kurzfristiger Workaround über Auskommentieren der Funktion wie oben beschrieben.

 

[ChrisTS]

Das Problem wird schlimmer, je mehr Weiterleitungen ihr auf einer Seite anzeigen lasst.

Da sind wir auch schon beim nächsten Problem. Der Shop generiert Haufenweise unsinnige URLS die offensichtlich durch Bots generiert werden.
Da geht dann zb. "url/artikel_22" weiter auf "url/artikel_56" weiter auf "url/artikel_19" und endet schlussendlich im unendlichen Universum bei zb. "url/artikel_7" den es garnicht gibt.

Auch werden Weiterleitungen nie gelöscht wobei diese ja aus Seo sicht gelöscht werden sollten sobald google diese im Index hat.

 

[MichaelH]

Wir haben das Entwickerticket noch einmal geöffnet und haben vermutlich von einem von euch auch ein offenes Ticket dazu. Wir schauen uns das also noch einmal an. Kurzfristiger Workaround über Auskommentieren der Funktion wie oben beschrieben.

Danke für die Lösung erstmal !

Die URL-Check Funktion ist neben den besseren Filtermöglichkeiten doch etwas Wert, daher sollte die Funktion erhalten bleiben.
Wenn das mit den "Sub-Tasks" nicht überall funktioniert, dann bitte optional einstellbar machen, dass es On-Line die angezeigten URLs prüft, ggf. mit separatem Button damit es beim Blättern nicht stört.
Die Wartezeit von ein paar Sekunden ist akzeptabel, dafür weiß man dass die Umleitungen mit 100ten Klicks auch tatsächlich funktionieren.

Vorgangsweise
Aufrufen (ggf. mit Filter)
Sortieren nach Häufigkeit absteigend
Klick auf prüfen
Blättern nächste Seite
Klick auf prüfen
....

Von 10.000en Weiterleitungen sind letztlich nur 100e wirklich wichtig.

Das wär' super !

 

[JulianG]

Da sind wir auch schon beim nächsten Problem. Der Shop generiert Haufenweise unsinnige URLS die offensichtlich durch Bots generiert werden.
Da geht dann zb. "url/artikel_22" weiter auf "url/artikel_56" weiter auf "url/artikel_19" und endet schlussendlich im unendlichen Universum bei zb. "url/artikel_7" den es garnicht gibt.

Auch werden Weiterleitungen nie gelöscht wobei diese ja aus Seo sicht gelöscht werden sollten sobald google diese im Index hat.

Du meinst damit, dass er die 404-Aufrufe dokumentiert. Tatsächliche Weiterleitungen (Quell und Ziel gefüllt) werden nur beim Abgleich automatisch erzeugt, wenn sich eine Produkt-URL ändert.
Die Erfassung von 404-Aufrufen kann man nur global aktivieren oder deaktivieren. Der Shop kann nicht unterscheiden welche sinnig und welche unsinnig ist. Grundsätzlich könnte man davon ausgehen, dass über längeren Zeitraum nur einmalig oder extrem seltene 404-Aufrufe nicht wirklich relevant sind. Alles was häufig aufgerufen wird, sollte geprüft werden. Nach der Pflege können alle ohne Ziel gelöscht werden.

Danke für die Lösung erstmal !

Die URL-Check Funktion ist neben den besseren Filtermöglichkeiten doch etwas Wert, daher sollte die Funktion erhalten bleiben.
Wenn das mit den "Sub-Tasks" nicht überall funktioniert, dann bitte optional einstellbar machen, dass es On-Line die angezeigten URLs prüft, ggf. mit separatem Button damit es beim Blättern nicht stört.
Die Wartezeit von ein paar Sekunden ist akzeptabel, dafür weiß man dass die Umleitungen mit 100ten Klicks auch tatsächlich funktionieren.

Vorgangsweise
Aufrufen (ggf. mit Filter)
Sortieren nach Häufigkeit absteigend
Klick auf prüfen
Blättern nächste Seite
Klick auf prüfen
....

Von 10.000en Weiterleitungen sind letztlich nur 100e wirklich wichtig.

Das wär' super !

Prüfung nach Bearbeitung findet ja weiterhin statt. Der Workaround verhindert nur, dass bei Aufruf ALLE angezeigten URL's geprüft werden. Man verliert also nur die direkte Übersicht über alle funktionalen URL's und wichtiger die nicht funktionalien, die bearbeitet werden müssten. Mit einem Prüfen Button würden trotzdem alle angezeigten geprüft werden, das bedeutet das Problem würde verschoben werden auf Buttonklick. Wir haben unserer Entwicklung hier den Vorschlag unterbreitet, ob es möglich wäre die angezeigten URL's gestaffelt zu prüfen. Das dauert dann ggf. eine Weile, aber es würden nicht x-Abfragen (je nachdem wieviele pro Seite angezeigt werden) auf einmal gestartet.

 

[MichaelH]

Prüfung nach Bearbeitung findet ja weiterhin statt. Der Workaround verhindert nur, dass bei Aufruf ALLE angezeigten URL's geprüft werden. Man verliert also nur die direkte Übersicht über alle funktionalen URL's und wichtiger die nicht funktionalien, die bearbeitet werden müssten. Mit einem Prüfen Button würden trotzdem alle angezeigten geprüft werden, das bedeutet das Problem würde verschoben werden auf Buttonklick. Wir haben unserer Entwicklung hier den Vorschlag unterbreitet, ob es möglich wäre die angezeigten URL's gestaffelt zu prüfen. Das dauert dann ggf. eine Weile, aber es würden nicht x-Abfragen (je nachdem wieviele pro Seite angezeigt werden) auf einmal gestartet.

Bearbeiten - ja, aber ich kann ja nicht alle anklicken um sie prüfen zu lassen.
Prüfen Button - der sollte eben On-Line prüfen und nicht über einen Task im Hintergrund, so hatte ich das geschrieben, womit es das Problem mit den Tasks nicht mehr gibt.

 

[JulianG]

Tut mir Leid, aber zumindest der Kollege neben mir und ich verstehen nicht was du meinst.

Das du nicht alle anklicken kannst zum prüfen ist klar, dafür wäre ja hoffentlich die gestaffelte Abfrage eine Lösung. Falls das nicht geht, findet unsere Entwicklung sicherlich eine andere Lösung. Wenn das Problem mit 4.06 weiterhin auftritt sollten nur definitiv nicht alle angezeigten gleichzeitig geprüft werden (wir haben noch keinen 4.06 Fall zur Prüfung via Ticket erhalten, aber Änderung ist in meinen Augen trotzdem sinnvoll).

 

[ChrisTS]

Du meinst damit, dass er die 404-Aufrufe dokumentiert. Tatsächliche Weiterleitungen (Quell und Ziel gefüllt) werden nur beim Abgleich automatisch erzeugt, wenn sich eine Produkt-URL ändert.
Die Erfassung von 404-Aufrufen kann man nur global aktivieren oder deaktivieren. Der Shop kann nicht unterscheiden welche sinnig und welche unsinnig ist. Grundsätzlich könnte man davon ausgehen, dass über längeren Zeitraum nur einmalig oder extrem seltene 404-Aufrufe nicht wirklich relevant sind. Alles was häufig aufgerufen wird, sollte geprüft werden. Nach der Pflege können alle ohne Ziel gelöscht werden.

In der Search Console haben wir etliche Umleitungsfehler.
Die Umleitungen werden vom Shop generiert. Da wird eine Seite hunderte male weitergeleitet und endet in einem Umleitungsfehler.
Ich glaub @css-umsetzung kann das besser erklären?

Sieht dann so aus??

 

[JulianG]

@Truckstyler
Das ist eigentlich ein komplett anderes Thema. Wenn der Shop die so automatisch generiert hat, dann weil ihr etliche Artikel (bzw. Objekte) habt, deren URL "scania-s-lederboden-styleline" heißen soll. Da jede URL nur einmal verwendet werden kann, muss der Shop hochzählen (_xx). Das ist aus SEO-Sicht absolut suboptimal. Wenn es jetzt größere Änderungen gab (inkl. temporärer Deaktivierung), kann es sein, dass sich die hochgezählten URL's im Bezug auf ihre zugehörige Artikel-IDs ändern und dann erzeugt der Shop automatisch Weiterleitungen.

Quellproblem: Keine einzigartigen URL's. Hier muss dann gepflegt werden. Jedes Objekt(Seite; auch jeder Kindartikel) sollte eine einzigartige URL erhalten. Das gilt auch für jede verwendete Sprache. Ihr solltet also entweder überall einzigartige Namen (z.B. Artikelnamen) pflegen, oder zumindest über den SEO-Namen für einzigartige URL's sorgen. Mehr zur SEO-Pflege in unserem Blog: https://www.jtl-software.de/blog/loesungen-von-partnern/seo-tipps-jtl-shop-einsteiger