Liebes Team, speziell @Arnaud,
wenn ich die Einschreibeseite der WebUI aufrufe (unter Klassenzimmer > Einschreiben, Seitentitel Enrolle), dann benötigt sie ca. 60 Sekunden Ladezeit, das war „früher“ nicht so, aber ich kann leider den Zeitpunkt nicht mit einem Update oder einer anderen Änderung am System in Verbindung bringen. Ich habe nach der Ursache gesucht und von den drei Abschnitten Schulklassen, Drucker, Projekte lädt nur der Zugriff auf die Projekte so lange, also der API Zugriff auf
Auf dem Server geht einer der Sambaprozesse auf Vollast >90% CPU:
samba: task[ldap] pre-forked worker <
Wenn ich die Projekte mit einem externen LDAP Browser abrufe geht die Abfrage innerhalb von 1 Sekunde durch.
Wenn ich den Loglevel hochsetze, sehe ich in den Samba logs nur, dass der global-binduser beim Laden der Seite sich sehr oft authentifiziert, aber es gibt keine Fehlermeldungen, die Seite lädt ja auch einwandfrei, nur eben viel länger…
Hat jemand Ideen zur Ursache, bzw. Problembehebung?
Der Server ist auf:
-Base…: 7.2.16-0
-Linbo…: 4.2.14-0
-WebUI…: 7.2.81
-Sophomorix…: 3.92.1-3
Wir haben 151 Projekte und 52 Schulklassen, aber keine Drucker über CUPS.
Ich glaube ich weiss, woran es liegen könnte: die Webui sucht rekursiv nach allen Mitglieder von allen Projekten, und bei Schulen die es intensiv nutzen, kann es lang dauern.
Wenn du dich traust, kannst du probieren die Datei /usr/lib/linuxmuster-webui/plugins/lmn_groupmembership/views.py Zeile 44 zu kommentieren:
project.get_all_members()
in
#project.get_all_members()
und dann die Webui neu starten, und schauen, ob es daran liegt.
Ich werde von meiner Seite auch anschauen.
vielen Dank für die schnelle Antwort. Ich habe die Zeile 44 auskommentiert und die Ladezeit ist unter 1 Sekunde. Du hattest also die richtige Idee. Vielleicht gibt es ja eine Optimierungsmöglichkeit in der Methode get_all_members im ldapconnector. In Python bin ich aber leider nicht so fit, dass ich sehe, was man da machen kann. Wir können erstmal auch mit der langen Ladezeit leben, da die Projekte ja nur selten verändert werden.
Lieber Arnaud,
vielen Dank für Deine Arbeit. Ich habe das ausprobiert und es ist so wie Du sagst, die Seite lädt schnell und die Anzahlen tauchen erst auf, wenn alle Requests fertig sind.
Gut: Man wundert sich nicht, dass die Seite so lange zum Laden benötigt.
Noch nicht so gut: Es wird nach wie vor nur ein samba-ldap Serverprozess verwendet, so dass die Arbeit insgesamt nicht parallelisiert ist und damit nicht kürzer dauert als vorher (unser Server hat 20 Kerne, aber jeder einzelne Kern hat nur 2,3GHz)
Problematisch: Als Lehrer denkt man jetzt, dass man sich sofort an die Arbeit machen kann, sobald man aber ein Projekt (während der im Hintergrund noch laufenden Requests) anklickt um Schüler einzutragen, wird die Seite so lange nicht aufgerufen, bis die komplette Anfrage durch ist.
Leider ist es daher in meinen Augen das eigentliche Problem nicht gelöst.
Viele Grüße, Adrian
Die Antwort habe ich befürchtet.
Ich verstehe nicht ganz, warum du von Samba sprichst, es sind reine Ldap-Requests, die parallel laufen, Aber die Oberfläche wartet, bis alle fertig sind.
Es gibt mehrere Wege um das ganze zu lösen:
Anzahl von MItglieder in die allgm View komplett abschalten (taucht aber in Projektdetails),
es konfigurierbar machen,
die verschiedene Mitgliederschaft cachen (großes und kompliziertes Thema),
usw …
Ich glaube wir werden es beim nächsten Entwicklertreffen ansprechen, da das Thema mit verschachtelten Gruppen (nested groups) auf dem Tisch kommen sollte.
ich schreibe von Samba, weil der Prozess, der so lange benötigt bei mir als
samba: task[ldap] pre-forked worker angezeigt wird (siehe Screenshot ganz oben)
In den Einstellungen habe ich maximal 8 solcher pre-forked worker Prozesse erlaubt, es wird aber von der WebUI nur einer verwendet.
Daher dachte ich, dass der beste Weg wäre die rekursive Abfrage auf mehrere solcher Prozesse zu verteilen oder alternativ die LDAP Anfrage zu optimieren.
Viele Grüße,
Adrian
@Michael : Der Ladebalken ist da, aber bei unserer Anzahl von Projekten beträgt die Ladezeit mehr als 60 Sekunden und das wird gerne als „hängen“ des Systems falsch verstanden.
Warum nicht einfach einen „Ladebalken“