bachelor-thesis/chapters/thesis/chapter06.tex

% !TeX root = ../../thesis.tex

\chapter{Evaluierung}
\label{ch:evaluation}

Nun werden die durchgeführten Anpassungen anhand ihre Effektivität betrachtet und unter welchen äußeren Einflüssen
diese eine Optimierung darstellen. Weiterhin werden die Nachteile der Anpassungen überprüft und und bei der Betrachtung
der Effektivität mit beachtet.

Es wurden die Konfigurationen der Caches von OpenJPA, JPA und EJB aktiviert und deren Auswirkung betrachtet. Bei den
Caches, bei denen eine Größe angebbar ist, wurde zusätzlich mit der Anzahl variiert, um zu ermitteln in welchen Umfang
sich diese auswirkt. Des Weiteren wird die Art der Programmierung für die Abfragen betrachtet, ob es signifikante
Unterschiede in der Performance und der Abarbeitung ergibt. Als weitere Punkt werden die Abfragen an die Datenbank
untersucht, um zu ermitteln ob diese durch Umstellung verbessert werden können. Als letzten werden die Materialisierten
Sichten verwendet, um zu ermitteln, ob durch einen vorverdichteten und aufbereiteten Datenbestand die Abfragen
beschleunigt werden können.

\mytodos{Zusätzlich beschreiben welche Möglichkeiten man genau genutzt hat und warum bzw. warum nicht}

\section{Nutzerumfrage}
\label{sec:evaluation:user-survey}

Zusätzlich war noch eine Befragung unter den Benutzer und den Entwicklern geplant. Da hierfür nur fünf Personen zur
Verfügung stehen, ist dies nicht zielführend. Daher ist die sinnvolle Alternative ein rein technischer Ansatz, der
gewählt wurde.

\section{Statische Webseiten}
\label{sec:evaluation:static-website}

Wenn man die Dokumentenliste als statische Webseiten ablegt, werden die Zugriffszeiten sehr kurz sein. Darüber hinaus
funktionieren in statische Webseiten aber keine Suche oder eine Sortierung. Die Sortierung könnte durch das erstellen
von statischen Seite aller Möglichkeiten der Sortierung emuliert werden, diese würde den notwendigen Speicherbedarf der
Webseite vervielfachen. Für die Suchanfragen ist dies nicht mehr möglich, da nicht alle Suchanfragen vorher definiert
werden können.

Die Umstellung der Suche auf Client"=Basis wäre noch eine Möglichkeit, dafür benötigen die Clients entsprechend
Leistung und es muss eine Referenzdatei erstellt werden, die alle Informationen über die Dokumente beinhaltet, nach der
gesucht werden kann.

Daher ist eine Umstellung auf statische Webseiten nicht sinnvoll.

\section{Client basierte Webseiten}
\label{sec:evaluation:client-side-rendering}

Als weitere Möglichkeit könnte man die Webseite so umbauen, dass die Daten erst im Nachgang über eine AJAX-Anfrage
ermittelt und die Sortierung und Aufteilung im Client durchgeführt wird. Hierbei wird aber je nach Datenmenge ein
großer Speicher am Client benötigt und die Rechenleistung wird auf den Client verschoben.

Dies wiederrum ist ein Vorteil für den Serverbetreiber, da durch die Verschiebung weniger Rechenleistung am Server
benötigt wird. Gleichzeitig würde man damit wiederrum schwächere Clients, wie Smartphones, aussperren, da bei diesem
die notwendige Rechenleistung fehlt, um die Webseite in annehmbarer Zeit darzustellen.

\section{Auswertung der Ergebnisse vor und nach der Optimierung}
\label{sec:evaluation:result-optimization}

\subsection{Caching im OpenJPA}
\label{sec:evaluation:result-optimization:caching-jpa}

Bei der Verwendung des OpenJPA"=Caches gibt es einige Verbesserungen in der Geschwindigkeit zu sehen. Die Höhe der 
Optimierungen hängt stark von der gewählten Cache"=Größe und der aufgerufenen Webseiten ab. Solange die Anfragen sich
auf die gleichen Objekte beziehen und diese alle im Cache hinterlegt werden können, fällt die Optimierung entsprechend
hoch aus. Sobald bei den Anfragen aber häufig die zu ermittelnden Objekt sich unterscheiden und alte Objekte wieder
aus dem Cache entfernt werden, fällt die Performance"=Verbesserung immer geringer aus. 

Das Entfernen der Objekte kann zwar umgangen werden, indem die häufig abgefragten Objekte gepinnt werden, was aber
den Speicherbedarf noch weiter erhöht, da diese Objekte nicht in die Zählung der Cache"=Objekte beachtet werden.
Was uns direkt zum größten Nachteil diese Caches kommen lässt, die notwendig Speichermenge die ständig zur Verfügung
gestellt werden muss. Damit ist immer ein gewisser Grundbedarf notwendig, da sich der Speicher bis zum eingestellten
Grenzwert aufbaut und dann nicht mehr entleeren wird. Gerade bei kleiner dimensionierten Servern stellt dies ein
größeres Problem dar, da dann weniger Speicher für die anderen laufenden Programme, wie dem Datenbankmanagementsystem,
zur Verfügung steht. 

Hierbei ist aber noch zu beachten, dass die Optimierung durch den Cache nicht die Laufzeit der Abfragen in der Datenbank
enorm verringert hat, sondern die Laufzeit beim erstellen der Objekte im \textit{OpenJPA}"=Framework. Dies sieht man
sehr gut schon bei der ersten Messung, wie in \autoref{tbl:measure-ojpa-active}. Hierbei werden die Laufzeit in der
Datenbank im Schnitt um circa 5 ms reduziert, aber die komplette Webseite wird fast 100 ms schneller an den Client
ausgeliefert. Dies ist nur dadurch erklärbar, dass das erstellen und mit den Datenwerte zu befüllen mehr Zeit kostet,
als das Objekt aus dem Cache zu ermitteln und zurückzugeben.

Daher ist die Verwendung des OpenJPA"=Cache nur in Verbindung mit einem größer dimensionierten Server gut verwendbar,
wenn der Großteil der Objekte im Cache gehalten werden kann. Bei Bedarf sollten die häufig frequentierten Objekte
explizit im Cache aufgenommen und angepinnt werden.

\subsection{Cached Queries}
\label{sec:evaluation:result-optimization:cached-queries}

Die Optimierung über die gespeicherten Anfragen brachte keine Verbesserung hervor. Dies ist dadurch erklärbar, dass
für die diese Art nur Anfragen verwendet werden, die keinerlei Bedingungen besitzen. Da in diesem Fall in der Tabelle
auch noch nicht freigegebene und ungültige Datensätze gespeichert sind, müssen diese vor dem übertragen herausgefiltert
werden. Dies ist der Grund warum diese Anfragen in diesem Cache nicht gespeichert werden.

Dadurch ist dieser Cache für eine Performance"=Verbesserung in unseren Fall nicht verwendbar.

\subsection{Caching mit Ehcache}
\label{sec:evaluation:result-optimization:ehcache}

\mytodos{fehlt noch}
Mit dem Ehcache konnte eine Verbesserung in der Performance erzielt werden. Im Vergleich zum Cache von OpenJPA sind
die Verbesserung sehr ähnlich. Die Standardwerte dieses Caches sind gut vordefiniert, es wird für den aktuellen Fall
keine Anpassung benötigt um eine gute Performance zu bekommen. Hierbei ist natürlich das gleiche Problem wie in anderen
Caches, dass beim erreichen der Grenzen, alte Objekte entfernt werden müssen.

Nach aktueller Beobachtung scheint die Verwaltung im Ehcache effizienter gestaltet zu sein, als die des OpenJPA"=Caches.
Im Falle des Ehcache ist die interne Verwaltung auf mehrere Caches aufgebaut, dies ist daran zu sehen, dass in der 
Standardkonfiguration jede Klasse ihren eigenen Cache besitzt. Diese können einzeln konfiguriert und diagnostiziert 
werden, um diese genau auf die jeweiligen Bedürfnisse der Objekte anzupassen.

Im Falle der Verwendung des Caches, ist auch hier gut zu sehen, dass der Speicheranstieg bei der Verwendung des Caches
sehr gering ist, was den Schluss zu lässt, dass der Cache nur zu einem kleinen 

Durch die effizienter Verwendung des Speichers, ist der Ehcache die bessere Alternative zum OpenJPA"=Cache. Dieser ist
auch schon für kleinere Serverkonfigurationen gut verwendbar. Hierbei ist nur abzuwägen, mit welcher Größe der Cache
bereitgestellt werden kann, was direkt am verfügbaren Arbeitsspeicher abhängt.

\subsection{Caching in EJB}
\label{sec:evaluation:result-optimization:ejb}

Bei der Erweiterung des EJB konnte keine Verbesserung in der Performance festgestellt werden. Dies liegt daran, dass
im EJB"=Cache die Provider beinhaltet, aber keine Daten"=Objekte. Dadurch kann der Cache das ermitteln der Objekte
nicht optimieren.

Aufgrund dessen ist der EJB"=Cache nicht für eine Performance"=Verbesserung nutzbar.

\subsection{Abfragen mit JPQL und Criteria API}
\label{sec:evaluation:result-optimization:jpal-capi}

Bei dem Vergleich zwischen den 2 Abfragemöglichkeiten der \ac{JPQL} und der Criteria API konnte in der Art der Abfragen
kein Unterschied dargestellt werden. Die Abfragen der beiden Systeme sind auf der Datenbankseite komplett identisch.
Auch in der Übertragung der Daten aus der Datenbank in die Java"=Objekte konnte keine Unterschied in der Art und
Geschwindigkeit festgestellt werden.

Ebenfalls sind die Möglichkeiten über der Optimierung über Hints identisch. In beiden Fällen, haben die meisten Hints
keine nennenswerten Einfluss auf die Laufzeit der Abfragen und Übertragung in die Java"=Objekte. Das sinnvolle setzen
von OptimizeResultCount, der FetchSize sowie der FetchBatchSize hilft dem Framework die Bearbeitung der Anfrage
effizient abzuarbeiten, konnte aber in den gemessenen Laufzeiten nicht verifiziert werden.

Anders ist dies mit dem Einstellungen für EagerFetchMode, welche definiert wie die Daten für abhängige Klasse ermittelt
werden. Bei Umstellung auf \textit{parallel} konnte für die Ermittlung der Dokumente einiges an Performance gewonnen
werden. Das liegt daran, dass nun für die abhängigen Objekte, wie den Koautoren, nicht pro Dokument eine Anfrage an die
Datenbank gestellt wird, sondern es werden alle Koautoren für die ermittelten Dokumente auf einmal ermittelt. Die
Zuordnung der Koautoren zu dem Dokument wird dann nun im Framework und nicht mehr durch die Datenbank durchgeführt.
Diese Abarbeitung spart viele einzelne Abfragen und somit auch den entsprechend Overhead im Framework.

Aufgrund dessen ist die Entscheidung der Technik für die Performance irrelevant und es kann das genutzt werden, was für
jeweiligen Einsatzzweck besser beziehungsweise einfacher zu programmieren ist. Das setzen der richtigen Hints wiederrum
ist in beiden Fällen äußerst wichtig. Explizit der EagerFetchMode muss vorher darüber nachgedacht werden, wie viele
abhängige Objekttypen es zu dieser Klasse gibt, welche dazu geladen werden sollen und von welcher Anzahl an Objekte 
ausgegangen werden kann. Gerade bei ein größeren Anzahl lohnt es sich den Hint auf \textit{parallel} zu setzen.
Gleiches gilt den Hint SubclassFetchMode, dieser steuert dimensionierten Abfragen im falle von abgeleitet Klassen.

\subsection{Materialized View}
\label{sec:evaluation:result-optimization:materialized-view}

\mytodos{hier weiter machen}
Mit der Verwendung der Materialisierten Sichten können
Die Idee der Materialisierten Sichten ist simple aber sehr effizient, gerade für einen Datenbestand der häufig gelesen
und selten verändert wird. Hierbei werden komplexe Abfragen einmalig ausgeführt und das Ergebnis intern 
zwischengespeichert wird. Für alle weiteren Aufrufe, werden die Daten nun aus der Sicherung gelesen. Technisch gesehen 
könnte dies auch selbständig implementiert werden, in dem zyklisch oder ereignisgesteuert das Ergebnis der Abfrage in 
eine Tabelle gespeichert wird.

Der Vorteil der Materialisierten Sichten ist, dass es einfach zu implementieren ist, eine geringere Fehleranfälligkeit 
aufweist und , da alles über die reine Sichtdefinition erstellt wird. Ebenfalls 

% verweisen auf doppelte Speicherung, ist zwar im cache das gleich, aber abzuwägen an welcher Stelle "mehr" zur 
% verfügung steht bzw. welcher Part günstiger in der Bereitstellung ist

\subsection{Optimierung der Abfrage}
\label{sec:evaluation:result-optimization:optimize-query}

\mytodos{fehlt noch}