Die Adminoberfläche läd extrem langsam

[ixtensa]

Hallo,

wir haben hier ein größeres webEdition-Projekt, das auf die neuste Version gebracht werden soll, da mittleweile Bugs behoben sein sollen, mit denen sich hier noch rumgeärgent wird.

Nun haben wir eine Kopie angelegt und dort das Update getestet. Nach einigen Templateanpassung läuft die Seite auch gut, aber es gibt noch ein Problem: Sowohl der Login zum Administrationsberech, als auch das laden des selbigen nach Eingabe der Zugangsdaten dauert ewig. Sobald aber endlich das Popup aufgeht, läuft alles flüssig.
Ist so ein Problem bekannt?

Das Projekt lief ursprünglich mal unter webEdition 5, wurde zwischenzeitlich auf 6.0.0.8 geupdatet und nun testweise auf 6.3.2.0.

[ixtensa]

Ok, folgende Query hält das laden der /webEdition/index.php ca. 1-2 min auf:

Code: Alles auswählen

SELECT ID FROM tblContent WHERE ID NOT IN (SELECT CID FROM tblLink)

aus folgender Funktion:

Code: Alles auswählen

we_updater::fixInconsistentTables();

Kommentiere ich den Aufruf aus, läd die Adminoberfläche wie gewohnt. Das kann aber wohl nicht sinn der Sache sein, oder?
tblContent und tblLink hatten bei diesem Test jeweils ca. 30000 Einträge.

[mokraemer]

Hast du nach dem Update mal das Fehlerlog (zum Update) angeschaut?

Ich vermute das da was drin steht, daß einzelne Indizes nicht angelegt werden konnten (duplicate keys).
In tblContent sollte die ID Primary Key sein.
In tblLink ist (CID,DocumentTable) Primary Key.

Damit kostet dieses Query nicht wirklich Performance. Vermutlich wird ein Problemfall beim Update bei Eurer Install noch nicht erfaßt!

Auf der Updateseite gibt es ja die explizite Empfehlung zuerst über die 6.2.7 zu gehen, bevor man die 6.3.2 einspielt.

[ixtensa]

Hast du nach dem Update mal das Fehlerlog (zum Update) angeschaut?

Wo wird das denn gespeichert?

Ich vermute das da was drin steht, daß einzelne Indizes nicht angelegt werden konnten (duplicate keys).
In tblContent sollte die ID Primary Key sein.
In tblLink ist (CID,DocumentTable) Primary Key.

Der Primary Key von tblLink fehlte, ich habe ihn manuell angelegt, die Query braucht aber nach wie vor um die 90 sec.

Auf der Updateseite gibt es ja die explizite Empfehlung zuerst über die 6.2.7 zu gehen, bevor man die 6.3.2 einspielt.

Das wurde wohl übersehen. Schade, dass der Updater das nicht automatisch berücksichtigt.
Dies war ja noch der Testlauf, bei der Live-Seite werde ichs berücksichtigen.

[ixtensa]

Ich habe es nun bei der Liveseite mit einem Schrittweisen Update 6.0.0.8 => 6.1.0.2 => 6.2.7.0 => 6.3.2.0 probiert. Das Ergebnis ist allerdings das gleiche, ich werde die Zeile also wohl auskommentieren müssen.

[ixtensa]

Was mir grad noch aufgefallen ist: In tblLink ist nun DID+CID Primary Key, nicht CID+DocumentTable.

[mokraemer]

hmm.
interessant - da muß ich noch mal in den Update Kode für die Tabellen reinschauen.
mach doch dazu bitte mal einen Bug in der Bugbase auf, sonst geht das vergessen! Am Besten mit Link auf den Thread.

Das ist in sofern auch recht wichtig, weil sich we auf das Vorhandensein der Indizes verläßt.

In WE gibt es 2 Logs:
1. Das Fehlerlog vom Update; Unter Hilfe, Update, Protokoll - das sollte unbedingt bei jedem Update gepfrüft werden v.a. wenn dort Fehler drin stehen. Idr. sollten da keine sein. Beim Update auf 6.3 können tatsächlich ein paar sein - das kann man hier dann aber erfragen.
2. Das Fehlerlog für alle Fehler die im laufenden Betrieb passieren, d.h. Fehler in Vorlagen, Fehler in WE selbst etc. Unter Hilfe, Fehlerlog.
Da sich einige Tags geändert haben, wird hier auch einiges geloggt, wenn tags falsch verwendet wurden, oder Vorlagen fehlerhaft sind.

[ixtensa]

mach doch dazu bitte mal einen Bug in der Bugbase auf, sonst geht das vergessen! Am Besten mit Link auf den Thread.

Mache ich gleich, hab eh grad nen anderen Bug gepostet, welcher mir beim Update aufgefallen ist.

1. Das Fehlerlog vom Update; Unter Hilfe, Update, Protokoll - das sollte unbedingt bei jedem Update gepfrüft werden v.a. wenn dort Fehler drin stehen. Idr. sollten da keine sein. Beim Update auf 6.3 können tatsächlich ein paar sein - das kann man hier dann aber erfragen.

Folgende Fehler stehen drin:

Code: Alles auswählen

tblPrefs.sql: Could not execute several queries. 1062 Duplicate entry '1' for key 1 -- ALTER TABLE `tblPrefs` ADD PRIMARY KEY (`userID`) -- 	6.0.0.8

tblLink.sql: Could not execute several queries. 1062 Duplicate entry '6365-tblFile' for key 1 -- ALTER TABLE `tblLink` DROP PRIMARY KEY , ADD PRIMARY KEY (`CID`,`DocumentTable`) -- 	6.1.0.2

tblPrefs.sql: Could not execute several queries. 1062 Duplicate entry '1' for key 1 -- ALTER TABLE `tblPrefs` ADD PRIMARY KEY (`userID`) -- 	6.1.0.2

tblLink.sql: Could not execute several queries. 1062 Duplicate entry '6365-tblFile' for key 1 -- ALTER TABLE `tblLink` DROP PRIMARY KEY , ADD PRIMARY KEY (`CID`,`DocumentTable`) -- 	6.2.7.0

tblPrefs.sql: Could not execute several queries. 1062 Duplicate entry '1' for key 1 -- ALTER TABLE `tblPrefs` ADD PRIMARY KEY (`userID`) -- 	6.2.7.0

tblTemporaryDoc.sql: Could not execute several queries. 0 -- -- 	6.2.7.0

2. Das Fehlerlog für alle Fehler die im laufenden Betrieb passieren, d.h. Fehler in Vorlagen, Fehler in WE selbst etc. Unter Hilfe, Fehlerlog.
Da sich einige Tags geändert haben, wird hier auch einiges geloggt, wenn tags falsch verwendet wurden, oder Vorlagen fehlerhaft sind.

Das hatte ich schon entdeckt, nette Sache, sowas haben wir in vorigen Versionen vermisst. Es gab auch einige Sachen in den Templates anzupassen, das passt aber jetzt.

[ixtensa]

Der Bugreport ist hier: http://qa.webedition.org/tracker/view.php?id=6671