Performance bei langsamer Internetanbindung

[Matthias Haake]

Hallo Nuclos-Team,

was können wir tun, um aus Nuclos auch bei langsamer Internetverbindung die bestmögliche Performance herauszukitzeln?

Anbindung sind ca. 2 MBit aber hohe Latenz, da mehrere tausend Kilometer.
Unsere Beobachtungen:
-Erster Start (Download der Java-App) ca. 4 Minuten
-Nach Eingabe der Logindaten weitere 1-2 Minuten Ladezeit
-Einfache Suchen funktionieren schnell (unter 1 Sek)
-Laden von Masken (recht komplex mit vielen Attributgruppen und Aktionen) bis zu 30 Sekunden

Es liegt definitiv an der zur Verfügung stehenden Bandbreite und nicht an der CPU/RAM (getestet mit dem selben Laptop an unterschiedlich angebundenen Standorten).

Die Startzeit ist irgendwie noch akzeptabel aber das Öffnen von Datensätzen (Masken) zehrt mit 30 Sekunden Wartezeit an den Nerven der Mitarbeiter.

Vermutungen, was die Performance verbessern könnte:
-Eigener Application Server am Standort (wird das irgendwann unterstützt?)
-Cachen der berechneten Layouts im Client, so dass ein erneutes Öffnen der Maske mit der gleichen Aktion vom Client nicht neu geladen werden muss

Ich freue mich über jeden Tipp. Bislang beschränkt sich das auf „möglichst wenige offene Tabs gleichzeitig“…

Viele Grüße,
Matthias

[Ramin Goettlich]

Hallo Matthias,

> -Erster Start (Download der Java-App) ca. 4 Minuten
Sie meinen sicherlich nur den allerersten Start, danach cached Java Webstart den Client ja lokal und lädt ihn nur dann neu, wenn die Nuclosinstallation auf dem Server aktualisiert wird (Upgrade auf neue Nuclosversion).

> -Nach Eingabe der Logindaten weitere 1-2 Minuten Ladezeit
Der Grossteil der Zeit geht hier dafür drauf, die clientseitigen Caches (z.B. Entitätsmetadaten etc.) mit den Daten vom Server zu befüllen. Da haben wir bereits geplant, die Caches lokal auf dem Client zu speichern und beim Starten des Clients nur noch zu prüfen, ob es aktuellere Daten gibt (ob z.B. jemand eine neue Entität angelegt hat o.ä.). Das wird in einer der nächsten Versionen umgesetzt werden.

> -Einfache Suchen funktionieren schnell (unter 1 Sek)

> -Laden von Masken (recht komplex mit vielen Attributgruppen und Aktionen) bis zu 30 Sekunden
Das ist uns bekannt und liegt vermutlich an zu vielen unnötigen Roundtrips. Im Rahmen eines Kundenprojektes profilen wir die entsprechenden Stellen momentan und werden hier Performanceverbesserungen mit der 3.2/3.3 einbauen.

Um ansonsten mehr rauszuholen, müssen Sie sich auf die Suche nach Dropdowns mit vielen Datensätzen begeben – und diese Dropdowns durch LOVs ersetzen. Die Befüllung der Dropdowns verursacht die wesentlichen Datenmengen, die dabei übers Netz gehen (was nebenbei bemerkt momentan – fälschlicherweise/unnötigerweise – auch noch doppelt geschieht: für die Detail- und für die Suchmaske). Manchmal lohnt es sich auch, kritische Dropdowns zumindest in der Suchmaske durch LOVs zu ersetzen, auch wenn man in der Detailmaske unbedingt eine Dropdown möchte. Vielleicht gibt es auch Suchmasken, in denen Sie ValueListProvider deaktiviert haben, so dass Dropdowns mit allen Daten befüllt werden, obwohl sie in der Suchmaske stark eingeschränkt wären. Typische Beispiele für sowas sind Liefer- und Rechnungsadressen, die in der Detailmaske über einen VLP nach Auswahl eines Kunden befüllt werden, diese Abhängigkeit in der Suchmaske aber vielleicht entfernt wurde.

Grüsse,
nuclosian

[Matthias Haake]

Hallo nuclosian,

vielen Dank für die prompte und ausführliche Antwort. Und ja, mit erstem Start meinte ich den Java Webstart.

Die Dropdowns haben wir bereits (wo sinnvoll) getauscht. Mehr als 10-15 Einträge in den Dropdowns kommen nicht vor, anderenfalls sind es bereits LOVs-Felder. Dann werden wir mal testen, ob wir bis Nuclos 3.2/3.3. so lange mit Terminal Services (RemoteApp) etwas besser fahren.

Wenn ich nochmal auf den zweiten Teil der Frage ansprechen darf: Ist eine Skalierbarkeit in Richtung mehrerer Application Server angedacht? Bei diesem Thema würde ich gerne auch das Stichwort unterschiedliche Zeitzonen mit in den Raum werfen (siehe NUCLOS-300).

Viele Grüße,
Matthias

[Markus Glitzner]

Hallo Mathias!

Da auch ich diese Probleme habe, kann ich dir vielleicht ein paar Tipps geben. Allerdings bekomme ich bei der Kommunikation mit dem Nuclos Server zumindest 4 MBit zusammen.

1. mal abgesehen von der langsamen Internet Verbindung, hab ich die Erfahrung gemacht, dass ältere (single core) Computer so gut wie nicht benutzbar sind, auch im selben LAN. Starten, Masken öffnen, Speichern, etc. ist sehr mühsam.

2. Entitäten mit Statusmodell sind generell langsamer, als Entitäten ohne Statusmodell, vor allem dann, wenn bereits viele Datensätze vorhanden sind. In einer der älteren Version war es sogar mal, dass die Wartezeit bei bestimmten Aktionen etwa linear mit der Anzahl der Datensätze in einer Entität gestiegen ist. Ob das immer noch so ist weis ich jetzt nicht.

3. Besonders knifflig wird es, wenn in einer Maske Comboboxen oder Unterformulare mit Beziehungen zu anderen Entitäten mit vielen Datensätzen sind, da kann das Laden der Maske schon mal zur Geduldsprobe werden. Nur hab ich da selber noch nicht so ganz durchgeblickt, wann es jetzt langsam ist und wenn nicht. Jedenfalls ist dass ein Problem im Nuclos Kern, nicht aber mit der Datenbank(verbindung).

4. Auch recht Problematisch ist, wenn in einem Unterformular viele Datensätze sind, dann geht das Laden zwar schnell, aber das Speichern dauert mehrere Minuten, auch wenn das Unterformular als readonly gekennzeichnet ist und das schon im selben LAN. Via WAN Verbindung hab ich letztens nach 10 Minuten abgebrochen und das Unterformular aus der Maske entfernt.

5. Anstatt das jeder Client die App vom Nuclos server lädt, kannst du den Java Cache Ordner vorab deployen. So muss nicht jeder die 60 MB verteil in 240 Dateien über die langsame WAN Verbindung herunterladen.

Gruß
Hugo

[Matthias Haake]

Vielen Dank Hugo. Besonders Tipp 5 gefällt mir gut, da das den Erstkontakt mit Nuclos etwas beschleunigt. An den Masken ist ohne weiteres nichts zu machen, die Subforms haben ja alle ihren Sinn und werden benötigt.

Das Laden bei vielen Daten ist optimiert worden, das merkt man deutlich.

Ich werde die Tage mal RemoteApp installieren und schauen, wie sich das verhält. Für die Benutzer ändert sich in der Bedienung ja nichts, die sehen ein normales Programmfenster bzw. das Abbild davon. Meine Erfahrungen werde ich im Thread hier posten.

Viele Grüße,
Matthias

[Markus Glitzner]

Hallo Matthias!

Habs schnell mal mit RemoteApps getestet, funktioniert so weit bis auf die geringe Farbtiefe, was die Nuclos Oberfläche etwas blas erscheinen läßt.

Ist halt etwas grotesk, einen Application Server für den Application Server :ohmy:

Gruß
Hugo

[Matthias Haake]

Hallo,

die ersten Messergebnisse mit dem Einsatz von RemoteApps liegen vor: eine deutlich bessere Performance. Die Übertragung der Bilder via RDP ist wesentlich schneller. Das Bild (Farbtiefe) sieht ok aus. Wir werden Nuclos an den dünn angebundenen Standorten also vorerst darüber betreiben.

Danke für all die Antworten und viele Grüße,
Matthias

[Ramin Goettlich]

Hallo,

> Wenn ich nochmal auf den zweiten Teil der Frage ansprechen darf: Ist eine Skalierbarkeit in Richtung
> mehrerer Application Server angedacht? Bei diesem Thema würde ich gerne auch das Stichwort
> unterschiedliche Zeitzonen mit in den Raum werfen (siehe NUCLOS-300).

Momentan nimmt der Nuclos Client keine Übersetzung von Uhrzeiten auf seine eigene Zeitzone vor. Beim Start des Nuclos Clients übernimmt dieser die Zeitzone des Servers, um gewisse Seiteneffekte beim Speichern von Daten zu vermeiden. In Nuclos gibt es aktuell auch noch keinen Datentyp „Uhrzeit“ oder „Datum mit Uhrzeit“ (von einer Sonderlösung bei den Editierungsdaten mal abgesehen), mit Einführung dieses Datentypen werden wir auch eine Berücksichtigung der Zeitzonen einführen.

Die Berücksichtigung der Zeitzone ist etwas, das auf Seiten des Clients geschehen muss. Uhrzeiten müssen gemeinsam mit der Zeitzone (oder normalisiert auf eine einheitliche Zeitzone) in der Datenbank gespeichert werden, der Application Server übergibt die gespeicherte Uhrzeit mit Zeitzoneninformation an den Client (und weiss prinzipiell ja auch gar nicht, in welcher Zeitzone der Client sitzt), der Client rechnet die Uhrzeit für eine Darstellung in den Masken oder im Kalender (Ressourcenplanung) dann auf seine eigene Zeitzone um. Mehrere Application Server bieten dafür in unseren Augen keinen anderen Weg.

Grüsse,
nuclosian

[Matthias Haake]

Hallo,

aus meiner Sicht verspricht ein Application Server in erster Linie mehr Performance und erhöht die Skalierbarkeit und in unserem Fall wäre das sehr willkommen.

Zum Thema Zeitzone: Wenn ich einen Standort in einer anderen Zeitzone habe, wird dieser Standort je nach Anbindung (z.B. MPLS) auch in einem separatem Netzwerkbereich sein (eigenes Subnet). Sicher könnte jetzt jeder Client selbst rechnen. Der Server könnte das aber auch, da alle lokalen Clients in der gleichen Zeitzone wären bzw. diese dem Server mitteilen, in welcher Zeitzone sich der Client befindet. Das würde die Clients entlasten und wenn man mal einen Thinclient baut (siehe Thread Webclient), müsste man das nicht alles erneut implementieren.

Viele Grüße,
Matthias

[Autor]

Beiträge