Daily CheckIn

chapters/expose/chapter01.tex

@@ -3,7 +3,7 @@
 
 \section{Ausgangslage}
 
-Die Grundlage zu dieser Arbeit bildet das DFG-Projekt "Edition der Korrespondenz Frank Wedekinds als Online-Volltextdatenbank".
+Die Grundlage zu dieser Arbeit bildet das DFG-Projekt \glqq Edition der Korrespondenz Frank Wedekinds als Online-Volltextdatenbank\grqq.
 Die folgende Übersicht hierzu ist eine Anlehnung an \citep{EffwFrankWedekind}.
 
 Die Editions- und Forschungsstelle Frank Wedekind (EFFW) wurde 1987 in der Hochschule Darmstadt gegründet. Ihr Intention
@@ -149,8 +149,8 @@ zurückliefern, aber nicht das Entity selbst. Hierbei kann genau gesteuert werde
 wird und welche nicht. Ebenfalls kann auf Klassenbasis der zugehörige Cache definiert werden, um eine bessere
 Last-Verteilung beim Zugriff zu ermöglichen \citep[314]{MüllerWehr2012}.
 
-Im \textit{Query-Cache} werden die Abfragen bzw. die Eigenschaften einer Abfrage und die zurückgelieferten Ids der
+Im \textit{Query-Cache} werden die Abfragen beziehungsweise die Eigenschaften einer Abfrage und die zurückgelieferten
-Entities gespeichert. Bei einen erneuten Aufruf dieser Abfrage werden die referenzierten Objekte aus dem
+Ids der Entities gespeichert. Bei einen erneuten Aufruf dieser Abfrage werden die referenzierten Objekte aus dem
 \textit{Objekt-Cache} zurückgegeben. Bei veränderten referenzierten Entities wird der \textit{Query-Cache} nicht 
 genutzt und die betroffenen Abfragen werden unverzüglich aus dem \textit{Query-Cache} entfernt
 \citep[316]{MüllerWehr2012}.
@@ -162,7 +162,7 @@ die Einstellungen an den Entities angepasst werden \citep{IbmOpenJPACaching2023}
 \subsection{PostgreSQL - Memory Buffers}
 
 Die Speicherverwaltung des PostgreSQL-Servers muss für Produktivsysteme angepasst werden \citep[34-38]{Eisentraut2013}. 
-Hierunter fallen die \textit{shared\_buffers} die bei ca. 10 bis 25 Prozent des verfügbaren Arbeitsspeichers liegen 
+Hierunter fallen die \textit{shared\_buffers} die bei circa 10 bis 25 Prozent des verfügbaren Arbeitsspeichers liegen 
 sollten. Mit dieser Einstellung wird das häufige Schreiben des Buffers durch Änderungen von Daten und Indexen auf die
 Festplatte reduziert.
 
@@ -191,7 +191,8 @@ Neben dem Aufräumen durch \texttt{VACUUM}, sollten auch die Planerstatistiken m
 Für beide Wartungsaufgaben gibt es den Autovacuum-Dienst, dieser sollte aktiv und richtig konfiguriert sein.
 
 Mit dem Tool \textit{pgFouine} \citep[155]{Eisentraut2013} können die Logs des PostgreSQL Server analysiert und auf
-Probleme hin untersucht werden. Hiermit können sehr einfach die häufigsten bzw. langsamsten Anfragen ermittelt werden.
+Probleme hin untersucht werden. Hiermit können sehr einfach die häufigsten beziehungsweise langsamsten Anfragen
+rmittelt werden.
 
 \subsection{PostgreSQL - Abfragen}
 

chapters/thesis/appendix01.tex

@@ -25,7 +25,7 @@ mit an, die ihnen zu den Problemen mit auffallen.
 
 \hfill
 
-Wir bedanken uns im Voraus für ihre Zeit und die Teilnahme an der Umfrage. Für die Umfrage benötigen Sie ca. 10 Minuten.
+Wir bedanken uns im Voraus für ihre Zeit und die Teilnahme an der Umfrage. Für die Umfrage benötigen Sie circa 10 Minuten.
 
 \hfill
 

chapters/thesis/appendix02_timing.sh

@@ -96,8 +96,8 @@ hostname="http://localhost:8080/WedekindJSF-1.0.0"
 # the Array of the Urls
 url_arr=(
     "$hostname/index.xhtml"
-    #"$hostname/view/document/list.xhtml"
+    "$hostname/view/document/list.xhtml"
-    "$hostname/view/document/listsearch.xhtml"
+    #"$hostname/view/document/listsearch.xhtml"
 )
 
 #print_process

chapters/thesis/chapter01.tex

@@ -24,17 +24,17 @@ um eine längere Bearbeitung anzuzeigen.
 \section{Ausgangslage}
 \label{sec:intro:initial-situation}
 
-Die Grundlage zu dieser Arbeit bildet das DFG-Projekt "Edition der Korrespondenz Frank Wedekinds als Online"=Volltextdatenbank".
+Die Grundlage zu dieser Arbeit bildet das DFG-Projekt \glqq Edition der Korrespondenz Frank Wedekinds als Online"=Volltextdatenbank\grqq.
 Die folgende Übersicht hierzu ist eine Anlehnung an \citep{EffwFrankWedekind}.
 
-Die Editions- und Forschungsstelle Frank Wedekind (EFFW) wurde 1987 in der Hochschule Darmstadt gegründet. Ihr Intention
+Die Editions- und Forschungsstelle Frank Wedekind (EFFW) wurde 1987 in der Hochschule Darmstadt gegründet. Ihre Intention
 ist es, den lange vernachlässigten Autor der europäischen Moderne in die öffentliche Aufmerksamkeit zu bringen. Die 
 Publikation der >>Kritischen Studienausgabe der Werke Frank Wedekinds. Darmstädter Ausgabe<<
 wurde direkt nach der Erschließung der Wedekind-Nachlässe in Aarau, Lenzburg und München begonnen und im Jahre 
 2013 abgeschlossen.
 
 Da der 1864 geborene Frank Wedekind heute zu einen der bahnbrechenden Autoren der literarischen Moderne zählt, aber bisher sehr
-wenig erforscht wurde, soll sich dies nun Ändern. Die nationalen und internationalen Korrespondenzen von und an Wedekind
+wenig erforscht wurde, soll sich dies nun ändern. Die nationalen und internationalen Korrespondenzen von und an Wedekind
 zeigen eine starke Vernetzung in der europäischen Avantgarde. Aktuell sind lediglich 710 der 3200 bekannten Korrespondenzstücke
 veröffentlicht worden.
 
@@ -51,7 +51,7 @@ eingesehen werden kann. Hierbei wurden sämtliche bislang bekannte Korrespondenz
 Briefe selbst werden im etablierten TEI-Format gespeichert und über einen WYSIWYG-Editor von den Editoren und
 Editorinnen eingegeben.
 
-Das Projekte wurde anhand von bekannten und etablierten Entwurfsmustern umgesetzt um eine modulare und unabhängige
+Das Projekt wurde anhand von bekannten und etablierten Entwurfsmustern umgesetzt um eine modulare und unabhängige
 Architektur zu gewährleisten, damit dies für weitere digitale Briefeditionen genutzt werden kann.
 
 \section{Ziel der Arbeit}
@@ -69,19 +69,20 @@ Hierbei ist auch ein Vergleich mit anderen Techniken angedacht.
 \section{Gliederung}
 \label{sec:intro:structure}
 
-Zu Begin der Arbeit werden im Kapitel \ref{ch:basics} die Struktur und der grundsätzliche Aufbau der Anwendung
+Zu Beginn der Arbeit werden im Kapitel \ref{ch:basics} die Struktur und der grundsätzliche Aufbau der Anwendung
 erklärt. Hierbei wird aufgezeigt an welchen Stellen es immer wieder zu Unstimmigkeiten kommen kann und wie diese zu
 überprüfen sind.
 
-Nachfolgenden wird im Kapitel \ref{ch:concept} die Konzepte vorgestellt, die die Stellen ermitteln, die eine schlechte
+Nachfolgend werden im Kapitel \ref{ch:concept} die Konzepte vorgestellt, die die Stellen ermitteln, die eine schlechte
 Performance aufweisen und optimiert werden sollen.
 Hierzu gehören zum einen die Einstellungen der verwendeten Software, und zum anderen der Aufbau und die verwendeten
-Techniken in der Anwendung. Diese Techniken werden im weiteren Verlauf nochmal überprüft ob eine alternative Lösung
+Techniken in der Anwendung. Diese Techniken werden im weiteren Verlauf nochmal überprüft, ob eine alternative Lösung
 einen performantere Umsetzung bringen kann.
 
 Bei den Performance"=Untersuchung in Kapitel \ref{ch:performance-checking} werden nun die Konzepte angewandt, um
-die Umgebung selbst zu Untersuchen und die dort bekannten Probleme zu ermitteln. Diese werden direkt bewertet, unter den
+die Umgebung selbst zu untersuchen und die dort bekannten Probleme zu ermitteln. Diese werden direkt bewertet, unter den
 Gesichtspunkten, ob eine Optimierung an dieser Stelle sinnvoll ist, oder ob der Arbeitsaufwand dafür zu enorm ist.
+\mytodos{das enorm sollte man umschreiben}
 Zusätzlich werden noch die Vorbereitungen und die angepassten Konfigurationen für die nachfolgenden
 Performance"=Untersuchung der Anwendung aufzeigt.
 

chapters/thesis/chapter02.tex

@@ -4,15 +4,15 @@
 \label{ch:basics}
 
 Da die Anwendung als Webseite umgesetzt ist, ist der zugehörige Client für den Benutzer ein Webbrowser. Dies bedeutet,
-das jeder Wechsel einer Seite oder eine Suchanfrage als Web"=Request an den Server geschickt wird. Solch ein Web"=Request
+dass jeder Wechsel einer Seite oder eine Suchanfrage als Web"=Request an den Server geschickt wird. Solch ein Web"=Request
 geht durch mehrere Schichten des Server"=System bis die Antwort an den Client zurückgesendet wird, wie in 
 \ref{fig:webrequest} dargestellt.
 
-Es wird ab hier immer von einem \textit{Glassfish}"=Server geredet. In der Praxis wird aber ein \textit{Payara}"=Server
+Es wird ab hier immer von einem \textit{Glassfish}"=Server geredet. In der Praxis wird ein \textit{Payara}"=Server
 verwendet. Der \textit{Glassfish}"=Server ist die Referenz"=Implementierung von Oracle, welche für Entwickler 
-bereitgestellt wird und die neuen Features unterstützt. Der \textit{Payara}"=Server ist aus dessen Quellcode entstanden,
+bereitgestellt wird und die neuen Features unterstützt. Der \textit{Payara}"=Server ist aus dessen Quellcode entstanden
 und ist für Produktivumgebungen gedacht, da diese mit regelmäßigen Aktualisierungen versorgt wird. In dem weiteren Text
-wird aber weiterhin der Begriff \textit{Glassfish} verwendet.
+wird weiterhin der Begriff \textit{Glassfish} verwendet.
 
 Angefangen bei der Anfrage die über den Webbrowser an den Server gestellt wird und vom \textit{Glassfish}"=Server
 empfangen wird. In diesem wird anhand des definierten Routing entschieden, an welchen \textit{Controller} im \ac{JSF}
@@ -29,7 +29,9 @@ sind die \textit{Memory Buffers} notwendig um den Zugriff auf die Festplatte zu
 zu verringern. Um Anfragen die den Zugriff auf die Festplatte benötigen effizienter zu gestalten, bereiten die 
 \textit{Services} die Datenstrukturen auf.
 
-\begin{figure}[h!]
+\mytodos{Grafik anders positionieren}
+
+\begin{figure}[h]
     \begin{tikzpicture}[node distance=5em,
         block/.style={rectangle, rounded corners,minimum width=3cm,minimum height=1cm,text centered, draw=black,fill=green!30},
         lineArrow/.style={arrows={-Latex[length=5pt 3 0]}},
@@ -115,7 +117,7 @@ zurückliefern, aber nicht das Entity selbst. Hierbei kann genau gesteuert werde
 wird und welche nicht. Ebenfalls kann auf Klassenbasis der zugehörige Cache definiert werden, um eine bessere
 Last-Verteilung beim Zugriff zu ermöglichen \citep[314]{MüllerWehr2012}.
 
-Im \textit{Query-Cache} werden die Abfragen bzw. die Eigenschaften einer Abfrage und die zurückgelieferten Ids der
+Im \textit{Query-Cache} werden die Abfragen beziehungsweise die Eigenschaften einer Abfrage und die zurückgelieferten Ids der
 Entities gespeichert. Bei einen erneuten Aufruf dieser Abfrage werden die referenzierten Objekte aus dem
 \textit{Objekt-Cache} zurückgegeben. Bei veränderten referenzierten Entities wird der \textit{Query-Cache} nicht 
 genutzt und die betroffenen Abfragen werden unverzüglich aus dem \textit{Query-Cache} entfernt
@@ -129,7 +131,7 @@ die Einstellungen an den Entities angepasst werden \citep{IbmOpenJPACaching2023}
 \label{sec:basics:memorybuffers}
 
 Die Speicherverwaltung des PostgreSQL"=Servers muss für Produktivsysteme angepasst werden \citep[34-38]{Eisentraut2013}. 
-Hierunter fallen die \textit{shared\_buffers} die bei ca. 10 bis 25 Prozent des verfügbaren Arbeitsspeichers liegen 
+Hierunter fallen die \textit{shared\_buffers} die bei circa 10 bis 25 Prozent des verfügbaren Arbeitsspeichers liegen 
 sollten. Mit dieser Einstellung wird das häufige Schreiben des Buffers durch Änderungen von Daten und Indexen auf die
 Festplatte reduziert.
 
@@ -159,7 +161,8 @@ Neben dem Aufräumen durch \texttt{VACUUM}, sollten auch die Planerstatistiken m
 Für beide Wartungsaufgaben gibt es den Autovacuum"=Dienst, dieser sollte aktiv und richtig konfiguriert sein.
 
 Mit dem Tool \textit{pgFouine} \citep[155]{Eisentraut2013} können die Logs des PostgreSQL Server analysiert und auf
-Probleme hin untersucht werden. Hiermit können sehr einfach die häufigsten bzw. langsamsten Anfragen ermittelt werden.
+Probleme hin untersucht werden. Hiermit können sehr einfach die häufigsten beziehungsweise langsamsten Anfragen
+ermittelt werden.
 
 \section{PostgreSQL - Abfragen}
 \label{sec:basics:queries}

chapters/thesis/chapter03.tex

@@ -16,7 +16,7 @@ Für die Untersuchung des Systems wird der direkte Zugang zum Server benötigt.
 
 Zuerst wird am PostgreSQL"=Server die Konfiguration der Speicher mit der Vorgabe für Produktivsystem abgeglichen.
 Hierunter fallen die Einstellungen für die \textit{shared\_buffers}, der bei einem Arbeitsspeicher von mehr als 1 GB
-ca. 25\% des Arbeitsspeicher definiert sein soll \cite{PostgresC20.4:2024}.
+circa 25\% des Arbeitsspeicher definiert sein soll \cite{PostgresC20.4:2024}.
 
 \mytodos{die anderen Speicher abarbeiten?}
 
@@ -47,7 +47,7 @@ die anderen Abfragen übertragen werden.
 
 Die Dokumentenliste zeigt direkte und indirekte Informationen zu einem Dokument an. Hierzu gehört die Kennung des
 Dokumentes, das Schreibdatum, der Autor, der Adressat, der Schreibort und die Korrespondenzform. Nach jeder dieser
-Information kann der Bediener die Liste auf"= oder absteigend sortieren lassen. Zusätzlich wird die Liste immer nach 
+Informationen kann der Bediener die Liste auf"= oder absteigend sortieren lassen. Zusätzlich wird die Liste immer nach 
 dem Schreibdatum sortiert, um die Ergebnisse bei gleichen Werten der zu sortierenden Informationen, wie dem Schreibort,
 immer in einer chronologisch aufsteigenden Form zu darzustellen.
 
@@ -65,9 +65,9 @@ weitere Relationen notwendig sind.
 \includecode[SQL]{chapters/thesis/chapter03_documentlist.sql}{lst:documentlist}{Generische Abfrage der Dokumentenliste}
 \includecode[SQL]{chapters/thesis/chapter03_documentlist_sub.sql}{lst:documentlist_sub}{Sub-Abfrage pro Dokument}
 
-Nach aktuellem Stand beinhaltet die Datenbank ca. 5400 Briefe, für die jeweils 2-7 eingescannte Faksimile gespeichert
+Nach aktuellem Stand beinhaltet die Datenbank circa 5400 Briefe, für die jeweils 2-7 eingescannte Faksimile gespeichert
 werden. Diese Graphik-Dateien werden im TIFF-Format abgespeichert und benötigen zwischen 1 und 80 MB Speicherplatz.
-Dadurch kommt die Datenbank aktuell auf ca. 3,8 GB.
+Dadurch kommt die Datenbank aktuell auf circa 3,8 GB.
 
 Wie im Kapitel \ref{ch:basics} dargestellt, besteht die eigentliche Anwendung aus mehreren Schichten. Die
 PostgreSQL"=Schicht wurde schon im vorherigen Kapitel betrachtet. Daher gehen wir nun weiter nach oben in den Schichten

chapters/thesis/chapter04.tex

@@ -24,7 +24,7 @@ prüfen, die den Cache von OpenJPE auswerten}
 
 Um eine Messung der Performance in der Webseite durchführen zu können, gibt es in \ac{JSF} die Möglichkeit, über eine
 eigene Implementierung der Klasse \textbf{ViewDeclarationLanguageWrapper} sich in das generieren der Webseite
-einzuhängen. Hierbei können die Funktionen für das erstellen, des bauen und das rendern der Webseite überschrieben
+einzuhängen. Hierbei können die Funktionen für das Erstellen, des Bauen und das Rendern der Webseite überschrieben
 werden. In den überschriebenen Funktionen werden nun Laufzeiten gemessen und die ermittelten Zeiten mit einer Kennung
 in die Log"=Datei eingetragen. Durch die Kennung, können die Zeiten im Nachgang über ein Script ermittelt und
 ausgewertet werden.
@@ -42,11 +42,11 @@ eingehängt. Diese Implementierung wird dann noch in der \textbf{faces-config.xm
 </factor>
 \end{lstlisting}
 
-Der Quellcode der Klassen ist im Anhang zu finden, unter \ref{ap:jsf_performance_measure} zu finden.
+Der Quellcode der Klassen ist im Anhang \ref{ap:jsf_performance_measure} zu finden.
 
 Um die Abfragen im \textit{PostgreSQL} untersuchen zu können, ist es am leichtesten, wenn man die Konfiguration so
 anpasst, dass alle Abfragen mit entsprechenden Zeitmessungen in die Log"=Datei des ausgegeben werden. 
-Zu erst werden über die Einstellungen unter \ref{lst:postgresql_logfile} die Datei und das Format definiert.
+Zuerst werden über die Einstellungen unter \ref{lst:postgresql_logfile} die Datei und das Format definiert.
 
 \begin{lstlisting}[language=yaml,caption={PostgreSQL Dateikonfiguration},label=lst:postgresql_logfile]
 log_destination = 'jsonlog'

chapters/thesis/chapter05.tex

@@ -3,7 +3,7 @@
 \chapter{Performance-Untersuchung der Anwendung}
 \label{ch:performance-investigation-application}
 
-Nun werden die unterschiedlichen Schichten betrachtet und möglichen Performance-Verbesserungen untersucht und deren
+Nun werden die unterschiedlichen Schichten betrachtet und möglichen Performance"=Verbesserungen untersucht und deren
 Vor"= und Nachteile herausgearbeitet.
 
 Für die Tests wird ein aktuelles Manjaro-System mit frisch installierten Payara als Serverhost und der IntelliJ IDEA
@@ -11,16 +11,16 @@ als Entwicklungsumgebung verwendet. Der Computer ist mit einer Intel CPU i7-1270
 als Systemfestplatte ausgestattet.
 
 Zur ersten Untersuchung und der Bestimmung der Basis-Linie, wurde das Script ohne eine Änderung an dem Code und der
-Konfiguration mehrfach aufgerufen. Hierbei hat sich gezeigt, dass der erste Aufruf nach dem Deployment ca. 1500 ms
+Konfiguration mehrfach aufgerufen. Hierbei hat sich gezeigt, dass der erste Aufruf nach dem Deployment circa 1500 ms
-gedauert hat. Die weiteren Aufrufe dauert dann im Durchschnitt noch 600 ms. Beim achten Aufruf des Scripts hat der
+gedauert hat. Die weiteren Aufrufe benötigen im Durchschnitt noch 600 ms. Beim achten Aufruf des Scripts hat der
 Server nicht mehr reagiert und im Log ist ein OutOfMemoryError protokolliert worden.
 
 Nach einem Neustart des Servers, konnte das gleiche Verhalten wieder reproduziert werden. Daraufhin wurde das Test-Script
 um die Anzeige der aktuellen Speicherverwendung des Payara-Servers erweitert und diese zeitgleich zu beobachten. Diese
-Auswertung zeigte, dass der Server mit ca. 1500 MB RSS Nutzung an seine Grenzen stößt. Diese Grenzen wurde durch die
+Auswertung zeigte, dass der Server mit circa 1500 MB RSS Nutzung an seine Grenzen stößt. Diese Grenzen wurde durch die
 Konfigurationsänderung im Payara-Server von \texttt{-Xmx512m} auf \texttt{-Xmx4096m} nach oben verschoben. Nun werden
-ca. 60 Aufrufe des Scripts benötigt, damit der Server nicht mehr reagiert. Hierbei wird aber kein OutOfMemoryError
+circa 60 Aufrufe des Scripts benötigt, damit der Server nicht mehr reagiert. Hierbei wird aber kein OutOfMemoryError
-in der Log-Datei protokolliert und der Server verwendet nun ca. 4700 MB RSS. Bei allen Tests war noch mehr als die
+in der Log-Datei protokolliert und der Server verwendet nun circa 4700 MB RSS. Bei allen Tests war noch mehr als die
 Hälfte des verfügbaren Arbeitsspeichers des Computers ungenutzt.
 
 Mit der Konfiguration \texttt{-Xmx} wird der maximal verwendbare Heap"=Speicher in der \ac{JVM} definiert. 
@@ -67,9 +67,11 @@ die Zeit der SQL-Abfragen nicht sichtbar ist}
 
 Vor jedem weiteren Test-Lauf wurde die Domain beendet und komplett neugestartet, um mit einer frischen Instanz zu
 beginnen. Hierbei ist aufgefallen, dass fast immer 62 Abfragen zur Startup-Phase dazugehört haben, unabhängig von den
-konfigurierten Cache Einstellungen. Einige dieser Abfrage sind durch das erstellen der Materialisierten Sicht 
+konfigurierten Cache Einstellungen. Einige dieser Abfragen sind durch das Erstellen der Materialisierten Sichten
-\textbf{searchreference} erklärbar. Diese Sicht wird für die Suche benötigt, und da diese Seite nicht betrachtet hier
+\textbf{searchreference} und \textit{searchfulltext} erklärbar. Zusätzlich ist noch ein zyklischer Dienst
-nicht betrachtet wird, wurde der Code für alle weiteren Tests deaktiviert.
+\textit{SearchEntityService} vorhanden, der zum Start und alle sechs Stunden den Datenbestand für die Suche aufbereitet
+und entsprechend einige Abfragen an die Datenbank absetzt. Da weder die Sichten noch der Dienst für die Dokumentenliste
+benötigt werden, wurde der Dienst und das Erstellen im Code für die weiteren Tests deaktiviert.
 
 Da die Abfragezeiten auf der Datenbank zu gering waren, um eine Verbesserung feststellen zu können, wurde für den
 PostgreSQL und den Payara-Server ein Docker-Container erzeugt und diese limitiert. Die Konfiguration ist im Anhang
@@ -115,12 +117,13 @@ zu laden, und in die Java-Objekte umzuformen.
 
 Hierfür wurde die aktuelle Datenstruktur untersucht um zu prüfen, ob eine Umgestaltung der Tabelle einen Verbesserung
 bringen würden. Die typische Optimierung ist die Normalisierung der Tabellenstruktur. Die Tabellenstruktur ist aktuell
-schon Normalisiert, daher kann hier nichts weiter optimiert werden.
+schon normalisiert, daher kann hier nichts weiter optimiert werden.
 
-Eine weitere optimierungsstrategie besteht in der Denormalisierung, um sich die Verknüpfungen der Tabellen zu sparen.
+Eine weitere Optimierungsstrategie besteht in der Denormalisierung, um sich die Verknüpfungen der Tabellen zu sparen.
 Dies ist in diesem Fall nicht anwendbar, da nicht nur 1:n Beziehungen vorhanden sind, sondern auch auch n:m Beziehungen.
 Dadurch würden sich die Anzahl der Dokumentenliste erhöhen. Oder man muss die Duplikate auf der Serverseite 
 zusammenführen.
+\mytodos{Gefällt der Verena nicht so}
 
 \section{Caching im OpenJPA}
 \label{sec:performance-investigation-application:caching-openjpa}
@@ -219,10 +222,9 @@ die \textit{SoftReference} nicht das Problem für den steigenden Arbeitsspeicher
     \label{tbl:measure-ojpa-active-bigger-no-softref}
 \end{table}
 
-
+Der Vergleich zeigt, dass der Cache eine gute Optimierung bringt, aber dies nur dann gut funktioniert, wenn immer
-Die Vergleich zeigt, dass der Cache eine gute Optimierung bringt, aber dies nur dann gut funktioniert, wenn immer
+wieder die gleichen Objekte ermittelt werden. Sobald die Anfragen im Wechsel gerufen werden oder einfach nur die Menge
-wieder die gleichen Objekte ermittelt werden. Sobald die Anfragen im Wechsel gerufen werden oder einfach nur der Menge
+der Objekte den Cache übersteigt, fällt die Verbesserung geringer aus.
-der Objekte den Cache übersteigt, fällt die Verbesserung gering aus.
 
 \section{cached queries}
 \label{sec:performance-investigation-application:cached-query}
@@ -281,7 +283,7 @@ abfragt.
 %% https://eclipse.dev/eclipselink/documentation/2.5/concepts/cache002.htm
 
 %Um den Cache zu deaktivieren wurden beiden Einstellungen auf \textit{false} gestellt, die Größe auf 0 und der Cache-Typ
-%auf \textit{NONE}. Hierbei lag die maximale gemessene Laufzeit des ersten Aufrufs bei ca. 1300 ms und es wurden 12219
+%auf \textit{NONE}. Hierbei lag die maximale gemessene Laufzeit des ersten Aufrufs bei circa 1300 ms und es wurden 12219
 %Abfragen an die Datenbank gestellt. Bei den nachfolgenden Aufrufe lag die Aufrufzeit im Durchschnitt bei 350 ms und
 %12080 Abfragen.
 
@@ -362,6 +364,40 @@ if(myResultList != null && !myResultList.isEmpty()) {
 Da dieser Code direkt so aus dem Projekt kommt, wird hierfür keine gesonderte Zeitmessung durchgeführt, da diese der
 Messung \ref{tbl:measure-without-cache} entspricht.
 
+Für die Optimierung wurden noch zusätzlich die Hints \textit{openjpa.hint.OptimizeResultCount},
+\textit{javax.persistence.query.fetchSize} und \textit{openjpa.FetchPlan.FetchBatchSize} gesetzt. Hierbei konnten je
+nach gesetzten Wert, keine relevanten Unterschiede festgestellt werden. Hierbei wurde der Wert auf zwei gesetzt,
+welcher viel zu gering ist. Als weiterer Test wurde der Wert auf angefragte Größte gestellt und auf den 20"=fachen
+Wert der angefragten Größe.
+
+Ebenso bringt der Hint \textit{openjpa.FetchPlan.ReadLockMode} auch keinen Unterschied bei der Geschwindigkeit. Hierbei
+ist erklärbar, da im Standard bei einer reinen Selektion eine Lesesperre aktiv sein muss.
+Bei \textit{openjpa.FetchPlan.Isolation} wird gesteuert, auf welche Sperren beim laden geachtet wird. Damit könnte man
+zwar schreibsperren umgehen, und würde damit die Anfrage nicht mehr blockieren lassen, aber es führt unweigerlich zu
+sogenannten \glqq Dirty"=Reads\grqq, wodurch die Ausgabe verfälscht werden könnte. Daher ist diese Einstellung sehr
+mit Vorsicht zu verwenden.
+
+Mit dem Hint \textit{openjpa.FetchPlan.EagerFetchMode} wird definiert, wie zusammengehörige Objekte abgefragt werden.
+Bei dem Wert \textit{none} werden nur die Basis"=Daten abgefragt und jedes weitere Objekt wird in einem eigenen
+Statement abgefragt. Mit \textit{join} wird definiert, dass abhängige Objekte die als \glqq to-one\grqq"=Relation
+definiert sind, in der Abfrage über einen Join verknüpft und damit direkt mitgeladen werden. Bei reinen 
+\glqq to-one\grqq"=Relation funktioniert das rekursive und spart sich damit einige einzelne Abfragen.
+Bei der Einstellung \textit{parallel} wird für zwar für jedes abhängigen Objektdefinition eine Abfrage durchgeführt,
+aber bei dieser wird der Einstieg über das Hauptobjekt durchgeführt. Somit muss in unserem Beispiel nicht für jedes
+Dokument eine einzelne abfrage für die CoAuthoren durchgeführt werden, sondern es wird nur eine Abfrage abgesetzt für
+alle Dokumente die ermittelt wurden. Technisch gesehen wird, die gleiche WHERE"=Abfrage nochmal durchgeführt und um
+die JOINS ergänzt, um die Daten der Unterobjekte zu ermitteln.
+Mit dem Hint \textit{openjpa.FetchPlan.SubclassFetchMode} ist die Konfiguraiton für Unterklassen definiert. Die
+Möglichkeiten entsprechen der vom \textit{openjpa.FetchPlan.EagerFetchMode}.
+
+Beim Umstellen der 2 Hints auf \textit{parallel} wird die Bearbeitungszeit fast halbiert und Anzahl der Datenbankaufrufe
+wurde fast geviertelt. Dies zeigt, dass die einzelnen Aufrufe je Dokument aufwendiger sind, als eine komplette Abfrage
+der abhängigen Daten und das zusammensetzen in der OpenJPA-Schicht.
+
+Der letzte Hint \textit{openjpa.FetchPlan.MaxFetchDepth} schränkt die rekursive Tiefe ein, für die abhängige Objekte
+mitgeladen werden. Damit wird zwar die Abfrage beschleunigt, aber nur aufgrund fehlender Datenbestände.
+\mytodos{besser formulieren}
+
 \section{Abfragen Criteria API}
 \label{sec:performance-investigation-application:query-criteria-api}
 
@@ -420,10 +456,15 @@ in den Java-Objekten fast identisch sind. Und in der Datenbank sind die Anfragen
     \label{tbl:measure-criteria-api}
 \end{table}
 
-Daher bringt die Criteria API keinen performance Vorteil gegenüber der JPQL!=Implementierung. Somit können beide 
+Daher bringt die Criteria API keinen performance Vorteil gegenüber der JPQL"=Implementierung. Somit können beide 
 Implementierung ohne bedenken gegeneinander ausgetauscht werden, und die verwendet werden, die für den Anwendungsfall
 einfacher umzusetzen ist.
 
+Bei den Hints ist es das gleiche wie bei \ac{JPQL}. Auch hier haben die meisten Hints keinen merkbaren Einfluss. Die
+Einstellung \textit{openjpa.FetchPlan.EagerFetchMode} liefert auch hier Optimierungen, wenn der Wert auf
+\textit{parallel} gestellt wird. Hier wird ebenfalls die Anzahl der Anfragen reduziert und damit auch die
+Geschwindigkeit optimiert.
+
 \section{materialized views}
 \label{sec:performance-investigation-application:materialized-views}
 
@@ -585,16 +626,23 @@ Nach dem Anpassungen haben sich dann die Werte aus \ref{tbl:measure-materialized
     \label{tbl:measure-materialized-view-ext}
 \end{table}
 
+\mytodos{prüfen ob ms oder msec die richtige SI-Einheit ist}
+
 Da bei der Materialized View das laden der Daten und das wandeln in die Java"=Objekte getrennt programmiert wurde,
 können hier eigene Zeitmessungen für die zwei Schritte eingebaut werden. Hierfür wird die Zeit vor dem
 \textit{map}"=Aufruf und der \textit{map}"=Aufruf gemessen. Für den ersten Aufruf, wurde ein \textit{SearchDocument}
 Objekt erzeugt und immer diese Objekt zurückgegeben. Damit wurde erst mal überprüft, wie lange das ermitteln der Daten
-und das durcharbeiten der Ergebnisse bestimmt. Hierbei lagen die Zeiten bei ca. 1 ms für das reine Datenladen und 3 ms
+und das durcharbeiten der Ergebnisse bestimmt. Hierbei lagen die Zeiten bei circa 1 ms für das reine Datenladen und 3 ms
 für den Aufruf der \textit{map}"=Funktion. Sobald mal innerhalb der \textit{map}"=Funktion pro Eintrag ein Objekt
 erzeugt, noch ohne eine Konvertierung der ermittelten Daten in das Objekt, steigt die Laufzeit schon auf 54 ms.
 Wenn man nun noch die Konvertierung der Daten wieder einbaut, steigt die Laufzeit nochmal auf nun 82 ms.
 Dies zeigt, alleine das erzeugen der Objekt kostet die meiste Zeit.
 
+Bei der Verwendung des Hints \textit{openjpa.FetchPlan.FetchBatchSize} kann die Abfrage enorm verschlechtern. Wenn
+dieser Wert zu klein oder groß definiert ist, wird die Laufzeit verschlechtert. Bei einem zu großen Wert wird die
+Laufzeit der Datenbankanfrage auf circa 20 ms verlängert. Wenn der Wert zu gering gewählt ist, dann wird zwar die
+Laufzeit der Datenbankanfrage minimal verkürzt, aber die \textit{map}"=Funktion wird dadurch verlängert.
+
 %\mytodos{hier noch darauf eingehen, dass die Hauptarbeit nicht beim editieren sondern bei der Anzeige ist}
 \mytodos{Hier könnte man auch den Query-Cache nochmal verwenden, da die anfragen nun fix wären}
 \mytodos{Grundlagen zur Materialized-View noch hinterlegen}