Vaadin unter Last – Teil 4: Performance-Verbesserung durch Lazy-Loading

Wir hatten in den ersten drei Teilen (1, 2, 3) der Serie eine Vaadin-Anwendung ausführlich unter Last gesetzt und vor allem ein Bottleneck festgestellt: das fehlende Paging (man könnte auch sagen: Lazy Loading) im Backend der Anwendung. Dieser Artikel diskutiert nun die Umsetzung von Lazy Loading in Vaadin und stellt die Test-Ergebnisse mit und ohne Lazy Loading gegenüber.

Es lassen sich drei Aspekte von Lazy Loading im Kontext von Server-seitigen Frameworks wie Vaadin unterscheiden:

  1. Nur wirklich nötige Zeilen zwischen Server und Client synchronisieren
  2. Nur wirklich nötige Zeilen auf Server-Seite ermitteln und laden
  3. Fähigkeit der Datenbank, einen Ausschnitt der Relation zu liefern

Die folgende Darstellung verdeutlicht die Problemstellung:

vaadin-lazy

Der erste Punkt (nur nötige Zeilen über das Netzwerk zum Client übertragen) ist von Vaadin intrinsisch gelöst – sprich: es wird immer und ohne weiteres Zutun nur das benötigte Minimum übertragen. Für den Entwickler ist damit grundsätzlich keine weitere Aktion nötig. Ebenso sind so gut wie alle relationalen Datenbanken in der Lage, einen Ausschnitt der Relation zu liefern. Dass sich das SQL zwischen den Datenbanken (leider) unterscheidet wird durch Frameworks wie JPA mitigiert (setFirstResult /setMaxResults).

Damit bleibt der Punkt Nummer zwei von oben zu lösen (in der Grafik gestrichelt umrandet): die Frage also, wie auf Server-Seite die benötigten Zellen ermittelt und selektiv aus den darunter liegenden Schichten ermittelt werden können. Man könnte auch sagen: auf Server-Seite zu ermitteln, wie weit der Benutzer herunter gescrolled hat und den aktuell sichtbaren Ausschnitt aus der Datenbank zu laden.

Die Vorteile eines durchgängig selektiven Ladens werden sehr schnell evident, wenn man sich eine größere Tabelle vor Augen hält: das Laden von 10.000 Records ist bereits fast prohibitiv Ressourcen-intensiv während der indizierte Zugriff selbst in Millionen Records (durch logarithmisches Wachstum) sehr wenig Ressourcen verbraucht (idealtypisch ca. 20 Vergleiche für die Positionierung innerhalb einer Million Records – abgeschätzt per Logarithmus dualis).

In Vaadin bieten sich dafür mehrere Lösungen an, die in der folgenden Tabelle kurz gegenübergestellt werden:

Ansatz Vorteile Nachteile
Einhängen in den Lebenszyklus des Server State Keine weitere Bibliothek nötig, schnelle + kompakte Lösung des Problems unter Wahrung von sauberer Schichten-Architektur Zusätzliches Einhängen eines Listeners nötig, der das Scrollen des Containers abfängt.
Nutzung eines Standard-Containers Offiziell (im Book of Vaadin) dokumentierter Weg, sehr hohe Kapselung Umgehen einer (sauberen) Schichten-Architektur – da direkter Zugriff auf die Datenbank (SQL-Container) bzw. die Persistenz (JPA-Container)
Lazy Query Container (unter Apache License verfügbar und auch im Code kompakt) Sauberes Einhalten einer Schichtenarchitektur, durchgängige Verwendung der Vaadin-Architektur (Datenbindung), Lösung an einer Stelle, Callbacks Zusätzliche Komponente (aber: Open Source + kompakt)

Ein Umgehen der Schichten-Architektur scheidet aus unserer Sicht sehr schnell aus. Das Einhängen in den Lebenszyklus des Server ist hier klar überlegen – und auch wenn diese Lösung (erprobterweise) funktioniert, so mangelt es ihr doch an Eleganz.

Der LazyQueryContainer ist ein Container, d.h. eine Datenquelle, an die z.B. Tabellen gebunden werden können. In einer MVP-Architektur (wie auch Officewerker eine ist) ist dieser Container (wie möglichst alle anderen Framework-abhängigen Klassen auch) Teil des View.

Um nun den LazyQueryContainer einzusetzen ist dieser als „ContainerDataSource“ in die Tabelle zu setzen:

Table tableItems = new Table();
/* this implementiert QueryFactory für Callbacks, die in ID_PROP_NAME genannte Property ist für jedes Item eine eindeutige ID, nach 50 nachladen, false = keine verschachtelten Items */
LazyQueryContainer items = new LazyQueryContainer(this, ID_PROP_NAME, 50, false);
// allPropertyNames – z.B. über getItemPropertyIds() des Item (ggf. Prototyp-Item anlegen)
for(String propertyName : allPropertyNames) {
items.addContainerProperty(propertyName, Long.class, null);
}
tableItems.setContainerDataSource(this.items);
// allVisiblePropertyNames ist ein Subset von allPropertyNames
this.tableItems.setVisibleColumns(allVisiblePropertyNames);

Mit diesen Schritten ist die Vaadin-Table mit dem LazyQueryContainer verbunden. Im obigen Beispiel wurde über this die Implementierung des Callback übergeben. Statt this wäre auch jedes andere Objekt denkbar – in jedem Fall aber muss die Schnittstelle org.vaadin.addons.lazyquerycontainer.QueryFactory implementiert werden. Wir haben das wie folgt gelöst (die Liste ist damit Read-Only – neue Items sind entweder nicht möglich oder benötigen im entsprechenden Code einen Neu-Aufbau der Tabelle. Letzteres ist fast immer ausreichend):

@Override
public Query constructQuery(QueryDefinition arg0) {
	return new QueryImpl();
}
private class QueryImpl implements Query {
	@Override
	public Item constructItem() {
		throw new UnsupportedOperationException("Kein Anlegen erlaubt");
	}
	@Override
	public boolean deleteAllItems() {
		throw new UnsupportedOperationException("Kein Löschen erlaubt");
	}
	@Override
	public List<Item> loadItems(int startIndex, int count) {
		// der Presenter registriert sich als Observer
		List<Invoice> invoiceList = observer.loadItems(startIndex, count);
		List<Item> resList = new ArrayList<Item>(invoiceList.size());
		for (Invoice invoice : invoiceList) {
			// wir brauchen wieder eine Item-Instanz
			resList.add(obtainItemFromBean(invoice));
		}
		return resList;
	}
	@Override
	public void saveItems(List<Item> arg0, List<Item> arg1, List<Item> arg2) {
		throw new UnsupportedOperationException("Kein Speichern erlaubt");
	}
	@Override
	public int size() {
		// der Presenter registriert sich als Observer
		return observer.size();
	}
}

Damit bekommen wir eine saubere Schichten- und MVP-Architektur hin: der Presenter registriert sich als Observer an der hier dargestellten View – und stellt die sehr geradlinige Methoden loadItems(startIndex, count) und size() zur Verfügung. Der Presenter wiederum kann über die Backend-Schichten an die Daten gelangen.

Auf den ersten Blick ist loadItems() nicht das, was man von einem Observer erwarten würde. Genauso erscheint das proaktive Abholen von Daten durch die View im Kontext von MVP auf den ersten Blick etwas seltsam. Auf den zweiten Blick allerdings wird das MVP-Muster sehr gut eingehalten: alle über die Anzeige hinausgehenden Funktionen werden im Presenter gekapselt. Auch bleibt der Presenter Unit-testbar (so dies nötig ist). Dem Presenter bleibt die Kontrolle über fachliche und inhaltliche Zusammenhänge – genau wie bei einem „buttonWasClicked“ oder einer anderen in MVP üblichen Methode. Dass wir die Daten als Return-Wert statt via Setter hineinreichen wird damit zum Detail.

Über die Verwendung von Callbacks haben wir allerdings die Möglichkeit geschaffen, Daten erst dann aus der Datenbank zu holen, wenn diese im Browser des Benutzers wirklich gebraucht werden.

Dies sollte sich massiv auf den Speicherverbrauch auswirken: Wiederholt man die Messung des Speicherverbrauchs mit 100 Threads lokal und misst im laufenden Test die Anzahl der Instanzen, so erhält man (vgl. Abbildung) noch 1900 Instanzen:

vaadin-lazy-res

Das bedeutet auch: wir liegen mehr als zwei Zehnerpotenzen unter dem Ausgangswert (von 900.000) – und haben absolut betrachtet eine komfortabel handhabbare Instanz-Zahl.

Mit anderen Worten: auch große Datenmengen lassen sich über Lazy Loading gut beherrschen. Da immer nur der sichtbare Teil + ein kleiner Puffer geladen wird hätten wir auch bei noch mehr Testdatensätzen kein anderes Ergebnis mehr – und skalieren damit sehr gut.

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s