Daily CheckIn

.vscode/settings.json

@@ -23,6 +23,7 @@
         "SFSB",
         "tabellenähnlichen",
         "unterlagerte",
+        "unterlagerten",
         "vorverdichteten",
         "Wallstein"
     ],

chapters/thesis/chapter03.tex

@@ -67,9 +67,8 @@ immer in einer chronologisch aufsteigenden Form zu darzustellen.
 
 Aktuell verwenden die Editoren die Dokumentenliste um die Briefe eines Adressaten zu filtern und diese in
 chronologische Reihenfolge aufzulisten und zu untersuchen wie Kommunikation zwischen Herrn Wedekind und dem Adressaten
-abgelaufen ist. Ebenso wird nach Standorten sortiert, um zu prüfen mit welchen Personen sich an den ...
-
-\mytodos{Hier noch mehr Infos dazu, für was genau die Editoren diese tun}
+abgelaufen ist. Ebenso wird nach Standorten sortiert, um zu ermitteln welchen Personen sich im Zeitraum am gleichen
+Ort aufgehalten haben.
 
 Da die Daten in der 3. Normalform in der Datenbank gespeichert werden, sind einige Relationen für die Abfragen
 notwendig. Dies wird durch die generische Abfrage in \ref{lst:documentlist} gezeigt. Zusätzlich wird für jedes

chapters/thesis/chapter06.tex

@@ -60,6 +60,18 @@ Dies wiederrum ist ein Vorteil für den Serverbetreiber, da durch die Verschiebu
 benötigt wird. Gleichzeitig würde man wiederrum schwächere Clients, wie Smartphones, aussperren, da bei diesem
 die notwendige Rechenleistung fehlt, um die Webseite in annehmbarer Zeit darzustellen.
 
+\section{Serverseitige Paginierung}
+\label{sec:evaluation:server-side-paging}
+
+Die Aufteilung eines großen Datenbestandes in mehrere einzelne Seiten, ist eine der wenige Optimierungsmöglichkeiten in
+der JSF"=Ebene. Dieser Einbau optimiert direkt an mehreren Stellen, dazu gehört die kleinere Datenmenge die vom 
+Datenbankserver geladen wird. Ebenso wird entsprechend weniger Zeit benötigt um die View zu erstellen und die zum
+Client übertragene Datenmenge ist auch geringer. Dadurch benötigt die Seite auf dem Client auch weniger Zeit zum
+rendern.
+
+Da das Paging für den Fall der Dokumentenliste implementiert ist, gibt es hier keine weiteren offensichtliche
+Optimierungsmöglichkeiten.
+
 \section{Caching im OpenJPA}
 \label{sec:evaluation:caching-jpa}
 
@@ -183,6 +195,11 @@ verlagert wurde. Hiermit konnte zum einen Last vom Server genommen werden und di
 optimieren. Die Wandlung der Daten in \textit{HTML}"=Objekte ist eine Kernkompetenz von JavaScript und damit auch bei
 schwächeren Clients in kurzer Zeit durchführbar.
 
+Als weiteren Punkt ist anzumerken, das der Speicherbedarf des Webserver relativ konstant bleibt ohne das ein Cache 
+verwendet wird. Der größte Unterschied zur Standardimplementierung ist die Verwendung von eigenen Code um die Objekte
+zu erstellen und zu befüllen und es nicht durch das OpenJPA"=Framework durchführen zu lassen. 
+Dies legt den Schluss nahe, dass es Probleme in der Speicherverwaltung der Objekte im OpenJPA"=Framework existieren.
+
 Zusammenfassend ist zu sagen, dass die \textit{Materialized View} eine gute Wahl sind, um die Listendarstellungen
 zu optimieren. Mit dieser Technik können zum einen die Abfragezeiten optimiert werden, wodurch gleichzeit die 
 Ressourcennutzung verringert wird. Zum anderen wird die Ressourcennutzung des Servers noch weiter reduziert, wenn die 

chapters/thesis/chapter07.tex

@@ -3,47 +3,84 @@
 \chapter{Zusammenfassung und Ausblick}
 \label{ch:summary_and_outlook}
 
-\mytodos{hier eine kurze Zusammenfassung über 2-3 Seiten}
+\mytodos{die 2 Untersektionen beibehalten?}
 
-\iffalse
-% umstellung auf matview sinnvoll bei verwendung von joins
-% bei joins von 1:n ist die Wandlung über json sinnvoll, aber parsen erst am client
+\section{Zusammenfassung}
+\label{sec:Summary_and_outlook:results}
+% In der Gegenwart schreiben, außer bei verweisen auf die Arbeit, dann in der Vergangenheit!
 
-!!! Hier nochmal die Nutzerumfrage mit einbringen 
+Die Untersuchungen am Beispiel des Wedekind"=Projektes zeigen, dass mehrere Optimierungsmöglichkeiten in den 
+Briefedition existieren. Für die Untersuchung wurde sich auf die Dokumentenliste beschränkt und anhand dieser
+die Optimierung implementiert, untersucht und jeweils mit der Ausgangsmessung vergleichen. Für die Messung wurden 
+Skripte erstellt, die auf dem gleichen Computer wie der Webserver und der Datenbankserver laufen, damit diese auch
+vergleichbar bleiben und externe Einflussfaktoren minimiert werden.
 
-- Einführung in die Ergebnisse
-- Darstellung der Kernergebnisse
-- Analyse und Interpretation
-- Einordnung in den Forschungskontext
-- Zusammenfassung und Übergang zur Diskussion
+\mytodos{den Absatz hier drin lassen oder raus?}
+%Messung zeigt wo die probleme liegen! hier noch ausformulieren
+Durch die Ausgangsmessungen war erkennbar, dass der größte Teil der Verarbeitungszeit im bereitstellen der Entitäten 
+benötigt wird. Die Messung der Abfragen auf der Datenbank wiederum konnte die hohe Verarbeitungszeit nicht bestätigen, 
+daher lag hier schon die Vermutung nahe, dass der Großteil der Zeit im ORM"=Mapper verloren geht.
 
-Du beginnst mit einer präzisen Beschreibung deiner Untersuchung, um ein klares Verständnis der Grundlagen zu schaffen, 
-und hebst spezifische Daten sowie Analysemethoden hervor (1).
+Die Methode der Nutzerumfrage wurde nicht weiterverfolgt, da diese aufgrund zu wenigen Bedienern nicht zielführend war.
+Bei der Untersuchung der Datenbank, wurde festgestellt, dass die Struktur aktuell für die Anwendung optimal ist und
+daher eine Restrukturierung keine Vorteile entstehen lässt. Die statische Webseite und die komplett Client basierte 
+Webseite wurde auf Grund von technischen Einschränkungen nicht weiterverfolgt.
 
-Anschließend präsentierst du die Kernergebnisse deiner Forschung klar und strukturiert, fokussierst dabei auf 
-relevante Entdeckungen, die direkt zur Beantwortung deiner Forschungsfrage beitragen (2).
+Bei den Caches sind der Query"=Cache und der EJB"=Cache nicht für die Optimierung verwendbar. Der Query"=Cache wird
+von OpenJPA nur verwendet, wenn die Abfragen keine Parameter besitzt, welche in der Dokumentliste verwendet werden
+mussten. Im EJB"=Cache werden nicht die Objekt, sondern die Provider gespeichert, wodurch hier keine Auswirkung auf die
+Performance festgestellt werden konnte.
 
-Eine tiefgehende Analyse folgt, in der du die Daten nicht nur beschreibst, sondern auch im Kontext der theoretischen 
-Grundlagen interpretierst und untersuchst, wie sie deine Hypothesen unterstützen oder herausfordern (3).
+Anders sieht es bei dem OpenJPA"=Cache aus, dieser hat direkten Einfluss auf die Performance der Ermittlung der Daten 
+und Bereitstellung der dazugehörigen Java"=Objekte. Anhand der vorgegeben Cache"=Größe kann das Potential der 
+Optimierung eingestellt werden. Dies bedeutet, soweit der Cache groß genug ist um alle notwendigen Objekte zu 
+speichern, sind die Verbesserung gut messbar. Ab dem Zeitpunkt, dass Objekte aus dem Cache entfernt werden müssen,
+wird die Optimierung immer geringer.
 
-Die Ergebnisse setzt du dann in den breiteren akademischen und praktischen Forschungskontext und diskutierst ihren 
-Beitrag zu bestehenden Theorien sowie die sich eröffnenden neuen Perspektiven (4).
+Ein sehr ähnliches Verhalten konnte mit dem Ehcache festgestellt werden, nur dass bei diesem die Limitierungen höher
+angesetzt sind und die Verwaltung des Caches im Gesamtsystem effizienter aufgebaut ist, als bei OpenJPA.
 
-Abschließend fasst du die wichtigsten Erkenntnisse zusammen und schaffst einen nahtlosen Übergang zur Diskussion, 
-indem du betonst, wie deine Ergebnisse die ursprünglichen Fragestellungen untersucht haben und welche Folgen sich für 
-weiterführende Forschungen ergeben könnten (5).
-\fi
+In beiden Fällen der Optimierung über die Nutzung eines Caches, konnte durch die Messungen in der Software und der
+Abfragen an der Datenbank nachgewiesen werden, dass nicht das Ermitteln der Daten die größte Zeit einnimmt, sondern
+das Erstellen und Befüllen der Objekte in Java.
 
-Das Ziel dieser Bachelorarbeit war es, durch die Untersuchung der Schichten am Beispiel des Wedekind"=Projektes 
-Optimierungsmöglichkeiten zu finden. Für die Untersuchung wurde sich auf die Dokumentenliste beschränkt und anhand
-dieser die Optimierungen implementiert, untersucht und jeweils mit dem Ausgangspunkt verglichen.
-Hierzu wurde der Aufbau der Software in seine unterschiedlichen Schichten zerlegt und diese einzeln Untersucht. 
-Für jede Schicht wurde 
-Bei den Schichten
-wurde, zu diesen zählen 
-die Enterprise Java Beans, die Java Persistance API, die OpenJPA, 
+Bei dem Vergleich der unterschiedlichen Abfragemethoden Criteria API und JPQL konnte keine Unterschied in der 
+Performance und Abarbeitung festgestellt werden. Bei beiden Methoden konnte nachgewiesen werden, dass die syntaktisch 
+gleichen Abfragen an die Datenbank gestellt wurden. Bei den Abfragen zur Dokumentenliste konnten in beiden Fällen
+durch die Umstellung der Ermittlung der unterlagerten Daten durch Hints eine Optimierung erreicht werden. Die Umstellung
+bezweckt das die unterlagerten Daten nicht einzeln für jede Zeile ermittelt wurde, sondern alle Daten auf einmal 
+geladen werden und die Zuordnung der Datensätze im OpenJPA"=Framework durchgeführt wird.
 
+Mit der übernahme der \textit{Materialized View} aus dem Wedekind"=Projekt konnte erstmalig ein gute Optimierung
+beobachtet werden. Dies ist auf die einfachere Abfrage, die Reduzierung der Abfrage an den Datenbankserver und das
+die Objekte in eigenen Code erstellt werden und nicht durch das OpenJPA"=Framework. Hierbei konnte noch nachgewiesen
+werden, dass das parsen der Json"=Daten, die die unterlagerten Objekte enthalten, den größten Teil der Zeit benötigen.
+Auf Grund dessen wurde das parsen der Json"=Daten auf den Client verschoben, was zu einem noch besseren Ergebnis führte.
 
-Für dieses Ziel wurde sich auf die Dokumentenliste beschränkt und diese jeweils
-für die unterschiedllichen Optimierungen angepasst.
-Es wurde 
+Für die Optimierung der Abfragen wurde die Hauptabfrage betrachtet. Bei dieser konnte anhand der visuell Darstellung
+das Problem gut identifiziert werden. Durch die Verwendung einer \textit{Common Table Expression} wurde die Anzahl
+der Datensatze direkt am Anfang auf die angefragte Menge reduziert, wodurch die Anzahl der zu betrachteten Datensätze 
+für die weiteren Verlinkungen enorm reduziert wurden. Somit konnte der Datenbankserver bei diesen Verlinkung auf Indexe 
+zugreifen und damit die Abfragen zusätzlich beschleunigen.
+
+Die Untersuchungen zeigen, dass mehrere Möglichkeiten zur Optimierung existierten, um die Zugriffe auf die 
+Briefeditionen zu beschleunigen und das das größte Optimierungspotential in den ORM"=Mapper vorhanden ist. Welche der 
+Optimierungen verwendet werden, liegt zum einen an der Komplexität der Abfrage und der bereitgestellten Ressourcen 
+des Servers.
+
+\section{Ausblick}
+\label{sec:summary_and_outlook:outlook}
+
+Die Untersuchungen zeigen, dass die Schichten über OpenJPA weitestgehend optimal umgesetzt sind, beziehungsweise wenig 
+Möglichkeiten für eine Optimierungen zu lassen. Einzig das parsen von Json ist in einem Webbrowser schneller als im 
+Server durchführbar. Auf diese Weise könnten zusätzlich die Ressourcen am Server reduziert werden, beziehungsweise mit 
+gleichen Ressourcen mehr Anfragen als bisher beantwortet werden.
+
+Die größten Optimierungspotentiale könne durch Umstellung der Abfragen und der Optimierung des ORM"=Mappers umgesetzt 
+werden. Bei den Umstellungen der Abfragen ist größte Stärke, wenn die Anzahl der Abfragen drastisch reduziert werden 
+können.
+
+Dadurch zeigt sich, dass die Untersuchung auf Ebene der ORM"=Mapper noch nicht abgeschlossen ist. Weitere Untersuchungen
+nach anderen ORM"=Mapper könnten wie in \ref{sec:evaluation:materialized-view} angedeutet das Speicherproblem lösen, 
+sowie eine generelle Optimierung der Webseite zur Folge haben. Eine eigenständige Implementierung eines einfachen 
+ORM"=Mapper wäre auch in Betracht zu ziehen, solange sich die Komplexität der Daten"=Struktur nicht erhöht.

frontbackmatter/thesis/AbstractDE.tex

@@ -4,19 +4,18 @@
 \begin{otherlanguage}{ngerman}
 	\pdfbookmark[0]{Zusammenfassung}{Zusammenfassung}
 	\chapter*{Zusammenfassung}
-	\mytodos{Dies am Ende noch Ausfüllen!!!}
+	Die Briefedition des Wedekind"=Projektes stellt die Korrespondenz von Frank Wedekind als Online"=Volltextdatenbank
+	zur Verfügung um die Forschung an Frank Wedekind zu fokussieren. Um die Akzeptanz der Webseite zu erhöhen, damit
+	weitere Forscher sich mit dem Thema beschäftigen, soll die Reaktionszeit für die Anfragen reduziert werden.
+	
+	Diese Arbeit betrachtet die verschiedenen Layer der Anwendung und die jeweiligen Optimierungsmöglichkeiten. Hierbei
+	wird ein rein technischer Ansatz gewählt, der durch Skript basierte Messungen überprüft und ausgewertet wird.
+	Betrachtet werden hierbei die Auswirkungen der verschiedenen Caches, die Abfragesprachen, eine Umstellung der 
+	Abfragen auf \textit{Materialized Views} und die Optimierungsmöglichkeiten der Abfragen.
 
-	Kurze Zusammenfassung des Inhaltes in deutscher Sprache von ca. einer Seite länge. Dabei sollte vor allem auf die folgenden Punkte eingegangen werden:
-	\begin{itemize}
-        \item Motivation: Wieso ist diese Arbeit entstanden? Warum ist das Thema der Arbeit (für die Allgemeinheit) interessant? Dabei sollte die Motivation von der konkreten Aufgabenstellung, z.B. durch eine Firma, weitestgehend abstrahiert werden. 
-        \item Inhalt: Was ist Inhalt der Arbeit? Was genau wird in der Arbeit behandelt? Hier sollte kurz auf Methodik und Arbeitsweise eingegangen werden.
-        \item Ergebnisse: Was sind die Ergebnisse der Arbeit? Ein kurzer Überblick über die wichtigsten Ergebnisse als Teaser, um die Arbeit vollständig zu lesen.
-	\end{itemize}
-	\medskip
-
-	\noindent
-	Eine großartige Anleitung von Kent Beck, wie man gute Abstracts schreibt, finden Sie hier:
-	\begin{center}
-        \url{https://plg.uwaterloo.ca/~migod/research/beckOOPSLA.html}
-    \end{center}
+	Es zeigt sich, dass die Ebenen unterschiedlich gute Optimierungsmöglichkeiten besitzen und die Caches die einfachste
+	Art der Optimierung sind, stattdessen benötigen diese zusätzliche Ressourcen im Sinne des Arbeitsspeichers.
+	Die Umstellung der \textit{Materialized View} inklusive der Zusammenfassung der unterlagerten Daten in eine Zeile
+	zeigt das größte Optimierungspotential. Durch die Umstellung der Abfragen kann ebenfalls die Verarbeitungszeit
+	reduziert werden, ist durch den größeren Anteil des ORM"=Mapper aber nicht stark ausschlaggebend.
 \end{otherlanguage}