Daily CheckIn

chapters/thesis/chapter05.tex

@@ -84,7 +84,7 @@ zeigt an, dass der verwendete Speicher nicht sauber freigegeben werden kann.
 
 Für die Ausführungszeiten der SQL-Abfragen wurden nur die sechs Abfragen für die Darstellung der Tabelle beachtet.
 Hierzu zählt die Hauptabfrage der Dokumenten"=-Tabelle, die Ermittlung des letzten und ersten Eintrags in der Tabelle,
-die Ermittlung der Adressen des Autors, die Ermittlung der CoAutoren, die Ermittlung der Faksimile, sowie die Ermittlung
+die Ermittlung der Adressen des Autors, die Ermittlung der Koautoren, die Ermittlung der Faksimile, sowie die Ermittlung
 der Anzahl aller vorhandenen Dokumente.
 
 Zusätzlich wird die Zeit des Rendern der Sicht gemessen. Hierbei wird zum einen die komplette Zeit des Renderns
@@ -616,7 +616,7 @@ Wie in Tabelle \ref{tbl:measure-materialized-view} zu sehen, bringt die Verwendu
 in verschiedenen Punkten. Zum einen ist eine Verbesserung der Aufrufzeiten zu erkennen, zusätzlich fällt der
 Speicheranstieg weniger stark aus. Die Verbesserung der Aufrufzeiten lässt sich zusätzlich erklären, dass hier nun
 nur noch vier statt der 6 Abfragen an die Datenbank gestellt werden, da einzelabfragen für die Adressen der Personen
-und der CoAutoren komplett entfallen.
+und der Koautoren komplett entfallen.
 
 Nach dem der Quellcode nochmal untersucht wurde, konnte man festellen, dass bei jeder Anfrage die gleiche Bedingung
 benötigt wurde. Da die Sicht nun explizit für dies Anfrage geschaffen wurde, wurde die Bedingungen nun direkt in Sicht

chapters/thesis/chapter06.tex

@@ -3,12 +3,118 @@
 \chapter{Evaluierung}
 \label{ch:evaluation}
 
-\mytodos{Hier noch darauf verweisen, dass eine Befragung unter den Benutzer und Entwickler nicht zielführend gewesen wäre, da zu wenige Anwender, 4 Stück,
+Nun werden die durchgeführten Anpassungen anhand ihre Effektivität betrachtet und unter welchen äußeren Einflüssen
-daher ist der rein technische Ansatz die einzige sinnvolle Wahl}
+diese eine Optimierung darstellen. Weiterhin werden die Nachteile der Anpassungen überprüft und und bei der Betrachtung
+der Effektivität mit beachtet.
+
 \mytodos{Zusätzlich beschreiben welche Möglichkeiten man genau genutzt hat und warum bzw. warum nicht}
 
-\section{Erneute Laufzeitanalyse starten}
+\section{Nutzerumfrage}
+
+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}
+
+\mytodos{prüfen wohin damit, hier oder odch in 5 lassen}
+
+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}
+
+\mytodos{prüfen wohin damit, hier oder odch in 5 lassen}
+
+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{Statistiken im PostgreSQL auswerten} 
 
 \section{Vergleich der Ergebnisse vor und nach der Optimierung}
+
+\subsection{Caching im OpenJPA}
+
+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{lst: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}
+
+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 in JPA}
+
+\subsection{Caching in EJB}
+
+\subsection{Abfragen mit JPQL und Criteria API}
+
+Bei dem Vergleich zwischen den 2 Abfragemöglichkeiten der \ac{JPQ} 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 Hit auf \textit{parallel} zu setzen.
+Gleiches gilt den Hint SubclassFetchMode, dieser steuert die Abfragen im falle von abgeleitet Klassen.
+
+\subsection{Materialized View}
+
+\mytodos{hier weiter machen}

chapters/thesis/chapter07.tex

@@ -1,3 +1,6 @@
+% !TeX root = ../../thesis.tex
 
 \chapter{Zusammenfassung und Ausblick}
 \label{ch:summary_and_outlook}
+
+\mytodos{hier eine kurze Zusammenfassung über 2-3 Seiten}