Ausgabe Frühjahr 2013 - Gedoplan

fert werden, um einen Bereich zu aktualisieren, findet der Austausch
bei Vaadin mit Hilfe der Frameworkeigenen UIDL, welche auf JSON
Basis realisiert ist, statt. Mit Hilfe dieser UIDL ist es möglich, die
Informationen in einer deutlich kompakteren Form auszutauschen.
Optimierung Vaadin
Ein extrem großer Teil des Datenverkehrs wird allein von der JavaScript-Engine
und insbesondere dem sogenannten Widgetset,
welches die Clientseitige Implementierung der Oberflächenkomponenten
beinhaltet, verursacht. Um also die Netzwerklast einer Vaadin-Anwendung
zu reduzieren, kann es sinnvoll sein, das Widgetset
noch einmal mit dem GWT-Compiler zu übersetzen. Mit Hilfe einer
eigenen BundleLoaderFactory kann für die einzelnen Komponenten
festgelegt werden, ob diese sofort bei Anwendungsstart oder „lazy“
im Programmverlauf geladen werden sollen. Wenn nur die Widgets,
die auch wirklich in der Anwendung benötigt werden, für das Eager-
Loading gekennzeichnet sind, so reduziert sich die Größe des Widgetsets
deutlich. Bei der hier vorgestellten Testanwendung konnte
eine Reduktion von ca. 1 MB auf gut 600 KB erzielt werden. Insgesamt
belief sich das Datenvolumen bei 100 Durchläufen nun nur
noch auf 101,17 MB gegenüber den vorher gemessenen 140,52 MB.
Optimierung JSF
Hier ist kein so offensichtlicher Optimierungsansatz gegeben. Sicher
würde die Anwendung anfänglich weniger Daten laden müssen, würde
man auf Primefaces verzichten, allerdings stände dann auch bei
weitem nicht der Funktionsumfang, wie er von Vaadin geboten wird,
zur Verfügung. Eine Möglichkeit, die Datenlast etwas zu senken,
bestünde darin, auf das Navigieren mit Redirect zu verzichten und
dafür zu sorgen, dass bei Seitenwechsel auch nur der Inhaltsbereich
per AJAX ausgetauscht wird, was dann allerdings erst einmal den
Verzicht auf Bookmarkable-URLs nach sich ziehen würde.
Optimierung Allgemein
Um für eine deutliche Absenkung der zu übermittelnden Datenmenge
zu sorgen, können die Seiteninhalte auch in gzip-komprimierter
Form an den Client ausgeliefert werden, sofern dieser das unterstützt.
Mit Hilfe der Datenkompression ist es gelungen, das gesamte
übertragene Datenvolumen, das in dem Testszenario angefallen ist,
im Falle von JSF auf 58,25 MB und bei der optimierten Vaadin-Anwendung
auf 36,92 MB zu drücken.
Überblick Datenmenge mit und ohne Optimierung:
Datenvolumen
Vaadin 140,52
JSF 178,20
Vaadin optimiert 101,17
Datenvolumen
durchschn. Paketgröße 58,25
Vaadin optimiert + GZIP 36,92
Fazit
Vaadin hat in diesem Testszenario eine geringere Netzwerklast verursacht
als JSF, was hauptsächlich über den AJAX-gestützten Seitenwechsel
und die UIDL, für den Informationsaustausch zwischen
Server und Client, zu erklären ist. Allerdings kann daraus natürlich
nicht allgemeingültig geschlossen werden, dass Vaadin-Programme
immer einen Vorteil in dieser Hinsicht gegenüber JSF-Anwendungen
haben. Schon allein der Einsatz einer anderen Komponentenbibliothek
für JSF oder das Implementieren einer AJAX-gestützten Navigation
könnten hier für einen großen Unterschied sorgen. Auch über
Nutzung eines anderen Themes könnte die Menge und Größe der zu
übertragenden Dateien beeinflusst werden.
Auffällig war vor allem bei Vaadin, dass der bei weitem größte Teil
der Datenmenge allein von dem anfänglichen Laden der Anwendung
herrührt. Das ist insofern interessant, als im Allgemeinen davon ausgegangen
wird, dass es sich bei der Datenlast, die durch das Verarbeiten
aller Aktionen auf dem Server entsteht, um einen der großen
Nachteile dieses Frameworks handelt. Natürlich ist bei solch einer
AJAX-gestützten Vorgehensweise die Anzahl der Anfragen an den
Server insgesamt größer, die Datenmengen, die dabei entstehen, fallen
allerdings wohl verhältnismäßig gering aus.
Es bleibt also festzuhalten, dass die Serverseitige Steuerung, die Vaadin
und JSF zu Grunde liegt, nicht unbedingt zu einer unverhältnismäßig
hohen Datenmenge führen muss. Daten für den Aufbau von
Seiten/Views und Styles sowie natürlich auch die in der Anwendung
darzustellenden und zu verarbeitenden Daten müssen bei jeder Webanwendung
zwischen Client und Server ausgetauscht werden. Wobei
es natürlich sehr schwer ist, hier allgemeine Aussagen diesbezüglich
zu treffen. Wenn man z. B. bei einer Webanwendung davon ausgeht,
dass diese von den Benutzern nur einmal am Tag geladen wird und
anschließend zehntausende verschiedene Aktionen darauf ausgeführt
werden, dann fällt natürlich auch irgendwann das Übertragen
jeweils kleiner Datenmengen (z. B. Validierung eines einzelnen Wertes)
stärker ins Gewicht.
Zur Optimierung von Webanwendungen empfiehlt es sich auf jeden
Fall, diese auch mit GZIP-Encoding anzubieten, da dies vor allem bei
den großen JavaScript-/CSS-/XML-/JSON-Dateien zu einer erheblichen
Reduktion des Datenvolumens führen kann.
Hendrik Jungnitsch [hendrik.jungnitsch@gedoplan.de ]
Entwickler und Trainer im Bereich Java bei der Gedoplan GmbH. Sein Tätigkeitsschwerpunkt
ist das Realisieren von Java-EE-basierten Webanwendungen.
10