Merkwürdige Wartezeit bei admin-Ansicht auf localhost

[svasti]

Hallo Leute,

ich habe hier eine merkwürdige Wartezeit, wenn ich mich nach dem Öffnen des Browsers zum ersten Mal auf localhost bei einer XH Site als Administrator einlogge. Nach dem Einloggen zeigt sich wie zu erwarten die entsprechende Seite im Bearbeitungsmodus, jedoch braucht XH etwa 30 Sekunden um zu einer anderen Seite oder einer Plugineinstellung zu kommen. Anschließend ist die Geschwindigkeit normal.

Ich dachte zuerst, das wohl irgend eine komische Konfiguration in meinem Computer schuld ist, aber ich habe dasselbe Phänomen auch auf dem neuen Computer eines Bekannten bemerkt.
Diese Phänomen tritt nur bei der 1.6er Reihe von XH auf, nicht bei der 1.5er etc,, und auch nur einmal bei ersten Einloggen in irgendeine XH-Site. Danach reagieren alle anderen XH-Sites normal.

Schließe ich den Browser und starte ihn wieder neu, beginnt das Spiel von neuem. Hä?
Apache/2.4.12 (Win32) OpenSSL/1.0.1l PHP/5.6.8

[lck]

Hallo svasti,

habe auch eine leichte Verzögerung nach dem Login, aber nur von ein paar Sekunden und wenn neben Xampp auch die Internetverbindung aktiv ist.
Ursache hierfür scheint das Plugin Hi_updatecheck zu sein. In der Standardkonfiguration ist "Autocheck" aktiviert. Schalt das mal aus, dann müsste es flutschen.

Diese Phänomen tritt nur bei der 1.6er Reihe von XH auf, nicht bei der 1.5er etc,, und auch nur einmal bei ersten Einloggen in irgendeine XH-Site. Danach reagieren alle anderen XH-Sites normal.

In früheren Versionen war hi_updatecheck im Installationspaket von CMSimple_XH noch nicht enthalten.

[svasti]

Hallo Ludwig, ja super, das war's.
Und bei der Gelegendheit konnte ich gleich noch ein Problem lösen. Ich habe/betreue nämlich eine Website, die nach dem Einloggen nicht mehr reagierte. Auf localhost funktioniert alles, aber auf dem Server gab die Website nach dem Einloggen keine Antwort mehr, die Bearbeitngsansicht erschien und das war's. Ende. Man konnte nichts mehr machen. Das war schon sehr doof. Hab jetzt den updatecheck rausgenommen und alles läuft wieder wie zu erwarten.

[Tata]

Ich wuerde dise Funktion default ausschalten und die Webmaster darauf vorbereiten, sie ab_und_zu zu nutzen, besonders, wenn etwas p!oezlich nicht stimmt.
(Mein Tablet hat die De Tastatur nicht installiert.)

[Holger]

Hallo Frank,

"AutoCheck" ausschalten hilft natürlich, aber ob es in jedem Fall die Lösung ist .
Wenn Du die Seiten aktiv betreust wird es ja kein Problem sein, da Du eventuell gemeldete (Sicherheits-)Updates ja auch auf andere Weise mitbekommst. Alternativ könntest Du auch den Timeout - Wert verringern. Dadurch wird die Zeit, die jedes Modul zur Prüfung bekommt, verringert.

ich habe hier eine merkwürdige Wartezeit, wenn ich mich nach dem Öffnen des Browsers zum ersten Mal auf localhost bei einer XH Site als Administrator einlogge. Nach dem Einloggen zeigt sich wie zu erwarten die entsprechende Seite im Bearbeitungsmodus, jedoch braucht XH etwa 30 Sekunden um zu einer anderen Seite oder einer Plugineinstellung zu kommen. Anschließend ist die Geschwindigkeit normal.

Die Updateprüfung funktioniert mit Ajax-Requests. Ein Klick, zum Beispiel auf den Pagemanager, sollte während der vermeintlichen Wartezeit aber eigentlich die Updateprüfung abschießen. Die Seite sollte also nicht wirklich blockiert sein.

Schließe ich den Browser und starte ihn wieder neu, beginnt das Spiel von neuem. Hä?

Nachdem die Prüfung einmal angestoßen wurde wird ein Session-Cookie gesetzt. Sobald dieser existiert, erfolgt keine erneute automatisch Prüfung. Daher funktioniert die Seite dann ohne Verzögerungen.

Blöd ist wirklich, dass das CMS beim ersten Login so aussieht als würde es für die Dauer der Updateprüfung "hängen". Das liegt an der Ladereihenfolge innerhalb von XH. Nach dem Login sieht man die Textarea mit dem Seiteninhalt, jetzt laden erst die Plugins und damit startet auch die Updateprüfung und erst dann lädt der WYSIWYG-Editor. Optisch entsteht der Eindruck, dass der Editor so ewig braucht bis er geladen ist.
Vielleicht genügt es schon wenn die (automatische) Updateprüfung erst dann beginnt wenn der User das erste Mal in den Ansichts-Mode schaltet?
Ich werde das mal testen. Oder hat vielleicht jemand eine bessere Idee?

Und bei der Gelegendheit konnte ich gleich noch ein Problem lösen. Ich habe/betreue nämlich eine Website, die nach dem Einloggen nicht mehr reagierte. Auf localhost funktioniert alles, aber auf dem Server gab die Website nach dem Einloggen keine Antwort mehr, die Bearbeitngsansicht erschien und das war's. Ende. Man konnte nichts mehr machen. Das war schon sehr doof. Hab jetzt den updatecheck rausgenommen und alles läuft wieder wie zu erwarten.

Wohl ein Fatal-Error durch den UpdateCheck. Da würde mich die Ursache aber sehr stark interessieren. Kannst Du vielleicht mal im Debug-Mode eine manuelle Prüfung anstoßen? Vielleicht könnte ich für solche Fälle die Server-Einstellungen besser prüfen und damit Fatal-Errors vermeiden. Aber eigentlich sollte das Skript unkritisch sein und einfach einen Fehler bei der Prüfung ausgeben, wenn es keinen Socket öffnen kann...

LG
Holger

[lck]

Es könnte auch an einer alten installierten Version von Hi_updatecheck liegen, Version 1.3 oder darunter. Mit Version 1.4 läuft die Udateprüfung wesentlich flotter, zumindest bei mir

[cmb]

ich habe hier eine merkwürdige Wartezeit, wenn ich mich nach dem Öffnen des Browsers zum ersten Mal auf localhost bei einer XH Site als Administrator einlogge. Nach dem Einloggen zeigt sich wie zu erwarten die entsprechende Seite im Bearbeitungsmodus, jedoch braucht XH etwa 30 Sekunden um zu einer anderen Seite oder einer Plugineinstellung zu kommen. Anschließend ist die Geschwindigkeit normal.

Das klingt sehr nach dem Problem, das Emile vor einer Weile berichtet hatte. Auch wenn der UpdateCheck assynchrone XHRs verwendet, kann es dennoch zum Blockieren kommen, da die Session von PHP gelockt sein könnte. Das ist eigentlich ein allgemeines Problem, für das ich erst mal keine Lösung sehe. PHP 7 bietet die Möglichkeit eine Session nur readonly zu öffnen, aber um das zu nutzen, müsste bereits beim Öffnen der Session bekannt sein, ob das genügt (oder ob geschrieben werden muss).

Für den UpdateCheck sollten wir vielleicht mal über CORS[1] oder JSONP nachdenken. Dann müssten die Requests nicht mehr über den eigenen Server laufen.

Und bei der Gelegendheit konnte ich gleich noch ein Problem lösen. Ich habe/betreue nämlich eine Website, die nach dem Einloggen nicht mehr reagierte. Auf localhost funktioniert alles, aber auf dem Server gab die Website nach dem Einloggen keine Antwort mehr, die Bearbeitngsansicht erschien und das war's. Ende. Man konnte nichts mehr machen. Das war schon sehr doof. Hab jetzt den updatecheck rausgenommen und alles läuft wieder wie zu erwarten.

Wohl ein Fatal-Error durch den UpdateCheck. Da würde mich die Ursache aber sehr stark interessieren.

Mich auch! Vor allem finde ich es sehr eigenartig, dass "die Bearbeitngsansicht erschien und das war's. Ende. Man konnte nichts mehr machen." Ist da etwa der Browser eingefroren, oder lag es an o.g. Problem?

Ich wuerde dise Funktion default ausschalten und die Webmaster darauf vorbereiten, sie ab_und_zu zu nutzen, besonders, wenn etwas p!oezlich nicht stimmt.

Darüber sollten wir wirklich nachdenken (obwohl damit sicher nicht alle Probleme bezüglich Session-Locks gelöst wären, und es vielleicht auch andere Lösungen für das UpdateCheck-Problem gibt, siehe oben).

PS: [1] CORS ist natürlich nicht hilfreich.

[svasti]

Es könnte auch an einer alten installierten Version von Hi_updatecheck liegen, Version 1.3 oder darunter. Mit Version 1.4 läuft die Udateprüfung wesentlich flotter,

Ja, das scheint's zu sein. Hatte 1.3 drin und damit "hing" der Server. Habe jetzt 1.4 hochgeladen und die Site reagiert wieder.

Ist da etwa der Browser eingefroren

Nein, hatte auch mit verschiedenen Browsern getestet. Die Bearbeitungsansicht öffnete sich ganz normal, auch der online Editor erschien, aber nach irgendeinem weiteren Befehl an den Server gab es keine Serverantwort mehr.

Kannst Du vielleicht mal im Debug-Mode eine manuelle Prüfung anstoßen?

Der Debug-Mode ist an, und die erste Bearbeitungsansicht offnete sich ohne Fehlermeldung und dann kamen gar keine Antworten mehr vom Server.

Das Problem scheint jetzt aber mit dem Update auf den aktuellen Updateprüfer gelöst. Also, vielen Dank an alle.

Ich könnte, wenn Interesse besteht, die alte Situation wiederherstellen und die Zugangsdaten per PM herausgeben.

[cmb]

Das Problem scheint jetzt aber mit dem Update auf den aktuellen Updateprüfer gelöst.

Das ist die Hauptsache.

[lck]

Das Problem scheint ja nur mit Version 1.3 von Hi_updatecheck zu bestehen, mit Version 1.4 konnte ich bisher keine Probleme feststellen

Hier mal meine Erfahrungen, sollte es noch jemanden interessieren.
Testumgebung:
Apache
PHP-Version 5.5.33
CMSimple_XH 1.6.7 (neu installiert)
Hi_updatecheck Version 1.3

Update-Check für:
CMSimple_XH
Jquery
Utf8_XH
Shariff (anstelle Shariff_XH, auch getestet mit Shariff_XH_light)
UpdateCheck
Pagemanager

1.) Updateprüfung dauert ca. 3,5min (Eigentlich sollte doch hier der eingestellte Timeout von 3s in der Konfiguration greifen?)
Ergebnis: Alle Update-Checks waren nach dieser Zeit erfolgreich, nur in der Zeile von "Sharff" erscheint ein "Fatal error" mit folgendem Inhalt:

Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 8192 bytes) in /var/www/hosts/.../.../___test/cmsimplexh167/plugins/hi_updatecheck/updatecheck.php on line 398

(Gleiches Verhalten und ähnliche Meldung kommt bei Shariff_XH_light:

Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 130968 bytes) in /var/www/hosts/.../.../___test/cmsimplexh167/plugins/hi_updatecheck/updatecheck.php on line 418)

2.) Ein Klick auf andere Links im Admin-Menü stoppt nicht die Updateprüfung, auch nicht ein Klick auf den Pagemanager.
3.) Der Browser friert nicht ein, nur die aktuelle Seite (getestet mit Chrome)
4.) Debug-Modus aktiv: Keine Fehlermeldung!

Deaktiviere ich das Plugin Shariff_XH (bzw. Shariff_XH_light), dann dauert die Updateprüfung nur 70ms.

Mit Hi_updatecheck Version 1.4 und Shariff_XH oder Shariff_XH_light, dauert die Updateprüfung nur 70ms.
Daumen hoch.