WebUI - Einschreibeseite hat lange Ladezeit

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

https://serverFQDN/api/lmn/groupmembership/projects.

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.

Vielen Dank, Adrian

Hallo Adrian,

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.

Gruß

Arnaud

Lieber Arnaud,

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.

Besten Dank, Adrian

Hallo Adrian,

Es tut mir leid, ich habe es nicht geschafft es noch vor die Pfingsferien anzuschauen, ich muss es für nach den Ferien verschieben.

Gruß

Arnaud

Lieber Arnaud, kein Eile, schöne Ferien!

Hallo Adrian,

Ich habe gerade es so angepasst, dass die Requests um alle Mitglieder zu holen später asynchron ausgeführt ist.

Das bedeutet:

  • die Seite ladet erst mal die Liste alle Projekte und sollte schnell auftauchen,
  • gleichzeitig im Background sind mehrere Requests für alle Requests geschickt, um die Mitgliederschaft rekursiv zu suchen,
  • wenn diese Requests fertig sind, dann tauchen die Anzahl von Mitglieder auf die Seite.

Das ist sehr wahrscheinlich nicht optimal, aber das wäre erst mal gut diese Lösung zu testen (kommt im nächsten Paket).

Gruß

Arnaud

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

Hi 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.

Gruß

Arnaud

Nur als Rückfrage gedacht:
:thinking: Warum nicht einfach einen „Ladebalken“
/ „lädt noch…“ davor⁉️

Lieber Arnaud,

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.

Ja, der „kleine gelbe am oberen Rand“ — vielleicht für so einen Fall besser sichtbar einblenden??