Daily CheckIn

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" #Materialized View
 )
 
 #print_process
@@ -108,5 +108,5 @@ echo ""
 main 10 ${url_arr[@]}
 
 echo ""
-##print_process
+#print_process
 print_docker_process

chapters/thesis/appendix04.tex

@@ -16,11 +16,11 @@ gestartet und initialisiert sind. Wenn dies nicht der Fall ist, laufen die Abfra
 wie dargestellt, über die Statistik von Docker zu ermitteln. Darüber wird überwacht, dass die CPU-Auslastung auf ein 
 niedriges Level fällt, danach kann das Skript für die Messungen aufgerufen werden.
 
-\includecode[bash]{chapters/thesis/appendix04_calling_script.sh}{lst:calling_script}{Calling Script}
-
 \begin{lstlisting}[language=Bash,caption={Aufrufe des Unterstützungsscriptes},label=lst:calling_script_exec]
 callscript.sh measinit
 callscript.sh -rppf=_testname measres
 callscript.sh dcstats
 callscript.sh -rppf=_testname measrun
-\end{lstlisting}
+\end{lstlisting}
+
+\includecode[bash]{chapters/thesis/appendix04_calling_script.sh}{lst:calling_script}{Unterstützungsscript}

chapters/thesis/appendix06.tex

@@ -11,7 +11,7 @@
 Für die Protokollierung der Abläufe im \ac{JSF} werden zwei Klassen benötigt. Über die Factory \ref{lst:logger_factory},
 wird die Wrapper"=Klasse in die Bearbeitungsschicht eingeschleust. Diese Wrapper"=Klasse \ref{lst:logger} beinhaltet
 dann die eigentliche Performance"=Messung, inklusive der Ausgabe in die Log"=Datei des \textit{GlassFish}"=Servers.
-Zusätzlich muss in der Konfiguration \texttt{faces-config.xml} noch angepasst werden, wie in
+Zusätzlich muss die Konfiguration \texttt{faces-config.xml} noch angepasst werden, wie in
 \ref{lst:logger_factory_activate}, um die Factory durch das System aufrufen zu lassen.
 
 \includecode[java]{chapters/thesis/appendix06_Logger.java}{lst:logger}{Vdi Logger}

chapters/thesis/chapter03.tex

@@ -27,7 +27,7 @@ Wenn der Speicher zu gering wird, werden die Zwischenergebnisse in temporäre Da
 berechnet sich aus \texttt{shared""\_buffers} dividiert durch \texttt{max\_connections} \citep{ConfigTo12:online}.
 Sollte die Berechnung außerhalb der Grenzwerte von 1 MB und 256 MB liegen, ist der jeweilige Grenzwert zu verwenden.
 Um zu ermitteln, ob die Konfiguration richtig ist, muss im PostgreSQL die Einstellung \texttt{log\_""temp\_""files} auf 0
-gesetzt werden. Mit dieser kann ermittelt, ob temporäre Dateien verwendet werden sowie deren Größe. Bei vielen kleineren
+gesetzt werden. Mit dieser wird ermittelt, ob temporäre Dateien verwendet werden sowie deren Größe. Bei vielen kleineren
 Dateien sollte der Grenzwert erhöht werden. Bei wenigen großen Dateien ist es ist sinnvoll den Wert so zu belassen.
 
 Für die Wartungsaufgaben wie VACUUM oder dem Erstellen von Indexen wird die Begrenzung über die Einstellung
@@ -36,7 +36,7 @@ als \texttt{work\_mem} sein.
 
 Nachfolgend wird mit dem Systemtools, wie den Konsolenanwendungen \textit{htop} und \textit{free}, die Auslastung des Servers 
 überprüft. Hierbei ist die CPU"=Leistung, der aktuell genutzte Arbeitsspeicher, sowie die Zugriffe auf die Festplatte
-die wichtigen Faktoren zur Bewertung.
+die wichtigen Faktoren zur Bewertung. %TODO wichtigsten?
 
 Die CPU"=Leistung sollte im Schnitt 70\% nicht überschreiten, für kurze Spitzen wäre dies zulässig, um die gestellten
 Anfragen schnell genug abarbeiten zu können. Daher soll verhindert werden, dass der Server an seiner Leistungsgrenze 
@@ -67,7 +67,7 @@ immer in einer chronologisch aufsteigenden Form darzustellen.
 
 Aktuell verwenden die Editoren die Dokumentenliste, um die Briefe eines Adressaten zu filtern und diese in
 chronologische Reihenfolge aufzulisten und zu untersuchen, wie die Kommunikation zwischen Herrn Wedekind und dem Adressaten
-abgelaufen ist. Ebenso wird nach Standorten sortiert, um zu ermitteln, welche Personen sich im Zeitraum am gleichen
+abgelaufen ist. Ebenso wird nach Standorten sortiert, um zu ermitteln, welche Personen sich in einem 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
@@ -79,12 +79,12 @@ weitere Relationen notwendig sind.
 \includecode[SQL]{chapters/thesis/chapter03_documentlist_sub.sql}{lst:documentlist_sub}{Sub-Abfrage pro Dokument}
 
 Nach aktuellem Stand beinhaltet die Datenbank circa 5400 Briefe, für die jeweils zwei bis sieben eingescannte Faksimile
-gespeichert werden. Diese Graphik-Dateien werden im TIFF-Format abgespeichert und benötigen zwischen 1 und 80 MB
+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 circa 3,8 GB.
 
 Wie in \autoref{ch:basics} dargestellt, besteht die eigentliche Anwendung aus mehreren Schichten. Die
 PostgreSQL"=Schicht wurde schon im vorherigen Kapitel betrachtet. Daher werden nun die weiteren Schichten des 
-GlassFish"=Server in aufsteigender Reihenfolge betrachtet.
+GlassFish"=Servers in aufsteigender Reihenfolge betrachtet.
 
 Die OpenJPA Cache Schicht wird nun einzeln untersucht. Hierfür werden zuerst die Cache"=Statistik für Object"=Cache
 und Query"=Cache aktiviert \citep[315]{MüllerWehr2012}. Die somit erfassten Werte werden über eine Webseite
@@ -122,16 +122,16 @@ Die Abfragen werden ebenfalls untersucht und mit verschiedenen Methoden optimier
 SQL"=Anfragen umgestellt und die Ausführungszeiten überprüft. Zum anderen werden die Abfragen durch Criteria API erzeugt
 und dessen Ausführungszeit ermittelt.
 
-Zusätzlich werden im SQL-Server Optimierungen vorgenommen, darunter zählen die \textit{Materialized View}, welche eine 
+Zusätzlich werden im PostgreSQL"=Server Optimierungen vorgenommen, darunter zählen die \textit{Materialized View}, welche eine 
-erweiterte Sicht ist. Neben der Abfrage der Daten beinhalteten diese auch vorberechneten Daten der Abfrage, womit 
+erweiterte Sicht ist. Neben der Abfrage der Daten beinhalteten diese auch vorberechnete Daten der Abfrage, womit 
 diese viel schneller abgefragt werden können. Zusätzlich werden die cached queries überprüft, ob diese eine Verbesserung 
-der Performance und der Abfragedauern verkürzen können.
+der Performance und damit eine Reduzierung der Abfragedauern erreichen.
 
-Damit die Messungen nachvollziehbar bleiben, werden die Testaufrufe durch ein Bash-Script automatisiert gerufen. 
+Damit die Messungen nachvollziehbar bleiben, werden die Testaufrufe durch ein Bash"=Script automatisiert gerufen. 
 Wichtig hierbei ist, dass die Webseite immer vollständig gerendert vom Server an den Client übertragen wird.
 Somit kann die clientseitige Performance ignoriert werden, da alle Daten bereits direkt in diesem einem Aufruf bereitgestellt
 werden. In dem Skript werden zum einen die Laufzeiten der Webanfragen ermittelt, zum anderen die kürzeste, die längste und die
-durchschnittliche Laufzeit ermittelt. Auf Grund der Speicherprobleme werden auch die Speicherbenutzung des
+durchschnittliche Laufzeit ermittelt. Auf Grund der Speicherprobleme wird auch die Speicherbenutzung des
 \textit{GlassFish}"=Servers vor und nach den Aufrufen ermittelt. Zum Schluss werden noch die Log"=Dateien des 
 \textit{PostgreSQL}"=Servers über das Tool \textit{pgBadger} analysiert und als Bericht aufbereitet.
 

chapters/thesis/chapter04.tex

@@ -77,7 +77,7 @@ log_rotation_size = 100MB
 
 Über die Konfiguration unter \autoref{lst:postgresql_logconf} wird definiert welche Werte protokolliert werden. Die
 wichtigste Einstellung ist \texttt{log\_min\_duration\_statement}, diese definiert, ab welcher Laufzeit eine Abfrage
-protokolliert werden soll. Mit dem Wert 0 werden alle Abfragen protokolliert. Alle weitere Einstellungen sind so
+protokolliert werden soll. Mit dem Wert 0 werden alle Abfragen protokolliert. Alle weiteren Einstellungen sind so
 gesetzt, dass nicht unnötige Abfragen für die spätere Auswertung mit \textit{pgBadger} protokolliert werden.
 Zusätzlich ist die Einstellung \texttt{log\_temp\_files} auf 0 zu setzen, dadurch werden alle erzeugten temporären
 Dateien und ihre Größe ebenfalls protokolliert. Diese Dateien entstehen, wenn der temporäre Puffer für die Abfrage
@@ -114,7 +114,7 @@ geschätzte Breite jeder Zeile (\textit{width}). Der Wert von \textit{costs} wir
 Bei der Option \texttt{ANALYZE} wird die Abfrage ausgeführt und die echten Werte und Laufzeiten angezeigt. Ohne diese
 wird nur der Plan erstellt und dargestellt. Durch \texttt{VERBOSE} wird der Abfrageplan um zusätzliche Informationen 
 angereichert. Die Option \texttt{BUFFERS} erweitert die Informationen über die Nutzung der Caches. Für eine
-Zusammenfassung am Ende des Abfrageplans, gibt es die Option \texttt{summary}. Eine vereinfachte Form des Aufrufs
+Zusammenfassung am Ende des Abfrageplans, gibt es die Option \texttt{SUMMARY}. Eine vereinfachte Form des Aufrufs
 ist in \autoref{lst:explain-easy} dargestellt.
 
 \begin{lstlisting}[language=SQL,caption={Aufruf von EXPLAIN},label=lst:explain-easy]
@@ -144,13 +144,13 @@ Daher muss abgewägt werden, ob die Performance-Verbesserung trotz der zusätzli
 als sinnvoll erachtet werden kann.
 
 Zusätzlich kann über die Systemtabelle \texttt{pg\_statistic} oder die lesbarere Systemsicht \texttt{pg\_stats} die
-aktuelle statistischen Informationen über eine Tabelle und deren Spalten ermittelt werden. In dieser Tabelle werden
+aktuellen statistischen Informationen über eine Tabelle und deren Spalten ermittelt werden. In dieser Tabelle werden
 durch das \texttt{ANALYZE} beziehungsweise \texttt{VACUUM ANALYZE} Kommando die Informationen zum Anteil der 
 \texttt{NULL}"=Werte (null\_frac), durchschnittlichen Größe (avg\_width), unterschiedlicher Werte (n\_distinct) und 
 weitere gesammelt und für die Erstellung der Abfragepläne verwendet \citep{PostgreS39:online}. Diese Information 
 sollte vor dem erstellen eines Index betrachtet werden.
 
-Diese Informationen können noch durch das Kommando \linebreak\texttt{CREATE STATISTICS} erweitert werden, für einen besseren
+Durch das Kommando \texttt{CREATE STATISTICS} können diese Informationen erweitert werden, um das erstellen des Abfrageplans
-Abfrageplan. Das Aktivieren der zusätzlichen Statistiken sollte immer in Verbindung mit der Überprüfung des
+zu verbessern. Das Aktivieren der zusätzlichen Statistiken sollte immer in Verbindung mit der Überprüfung des
 Abfrageplans durchgeführt werden, um zu ermitteln inwieweit die Anpassung zu einer Optimierung und keiner 
 Verschlechterung führt.

chapters/thesis/chapter05.tex

@@ -15,9 +15,9 @@ Konfiguration mehrfach aufgerufen. Hierbei hat sich gezeigt, dass der erste Aufr
 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 \textit{OutOfMemoryError} protokolliert worden.
 
-Nach einem Neustart des Servers konnte das gleiche Verhalten wieder reproduziert werden. Daraufhin wurde das Test"=Script
+Nach einem Neustart des Servers konnte das gleiche Verhalten wieder reproduziert werden. Daraufhin ist eine Erweiterung
-um die Anzeige der aktuellen Speicherverwendung des Payara"=Servers erweitert, um diese zeitgleich zu beobachten. Diese
+des Test"=Scripts notwendig, um die aktuellen Speichernutzung des Payara"=Servers darzustellen und auszuwerten. Diese
-Auswertung zeigte, dass der Server mit circa 1500 MB RSS Nutzung an seine Grenzen stößt. Diese Grenze wurde durch die
+Auswertung zeigte, dass der Server mit circa 1500 MB RSS Nutzung an seine Grenzen stößt. Diese Grenze wird durch die
 Konfigurationsänderung im Payara-Server von \texttt{-Xmx512m} auf \texttt{-Xmx4096m} nach oben verschoben. Nun werden
 circa 60 Aufrufe des Scripts benötigt, damit der Server nicht mehr reagiert. Hierbei wird aber kein \textit{OutOfMemoryError}
 in der Log-Datei protokolliert und der Server verwendet nun circa 4700 MB RSS. Bei allen Tests war noch mehr als die
@@ -32,7 +32,7 @@ Aufrufe steuert. Die Ergebnisse werden in eine Tabelle überführt, wie in \auto
 Hierbei werden die Aufrufzeiten der Webseite aus dem Skript für die Zeitmessung mit Mindest"~, Durchschnitt"~ und
 Maximalzeit aufgenommen, hierbei ist eine kürzere Zeit besser. Zusätzlich wird die Anzahl der aufgerufenen \ac{SQL} Abfragen
 ermittelt, auch hier gilt, je weniger Aufrufe desto besser. Als letztes wird noch der verwendete Arbeitsspeicher
-vom \textit{GlassFish}"=Server vor und nach dem Aufruf ermittelt und die Differenz gebildet, hierbei sollte im idealen
+vom \textit{Payara}"=Server vor und nach dem Aufruf ermittelt und die Differenz gebildet, hierbei sollte im idealen
 Fall die Differenz bei 0 liegen. Dieser Aufbau gilt für alle weiteren Messungen. Zusätzlich werden noch die Laufzeiten
 der \ac{JSF} ermittelt und die durchschnittlichen Zeiten mit in der Tabelle dargestellt, und auch hier ist es besser,
 wenn die Zeiten kürzer sind.
@@ -63,14 +63,14 @@ gehalten werden sollten.
 \end{table}
 
 Vor jedem weiteren Test"=Lauf wird 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
+beginnen. Hierbei ist aufgefallen, dass fast immer 62 Abfragen zur Startup-Phase dazugehören, unabhängig von den
 konfigurierten Cache Einstellungen. Einige dieser Abfragen sind durch das Erstellen der \textit{Materialized View}
 \textit{searchreference} und \textit{searchfulltext} erklärbar. Zusätzlich ist noch ein zyklischer Dienst
 \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.
+benötigt werden, ist 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
+Da die Abfragezeiten auf der Datenbank zu gering sind, um eine Verbesserung feststellen zu können, wird für den
 PostgreSQL und den Payara"=Server ein Docker"=Container erzeugt und diese limitiert. Die Konfiguration ist in 
 \autoref{ap:docker_config} beschrieben.
 
@@ -79,13 +79,13 @@ Speicher der Anwendung beobachtet, sondern die Speichernutzung des Docker-Contai
 ist es besser, wenn es keine oder nur geringe Änderungen vor und nach dem Aufruf der Webseite gibt, ein steigender Wert
 zeigt an, dass der verwendete Speicher nicht sauber freigegeben werden kann.
 
-Für die Ausführungszeiten der \ac{SQL}"=Abfragen wurden nur die sechs Abfragen für die Darstellung der Tabelle beachtet.
+Für die Ausführungszeiten der \ac{SQL}"=Abfragen werden 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,
+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 Koautoren, die Ermittlung der Faksimile, sowie die Ermittlung
 der Anzahl aller vorhandenen Dokumente.
 
 Zusätzlich wird die Zeit des Rendern der Sicht gemessen. Die erste Messung erfasst die komplette Laufzeit die fürs Rendern
-notwendig benötigt wird. Diese Zeit wird unterteilt in die Messungen für das Laden der Daten aus der Datenbank und das Erstellen
+notwendig ist. Die zweite Messung ermittelt die Zeit für das Laden der Daten aus der Datenbank und das Erstellen
 der Java"=Objekte inklusive dem Befüllen mit den geladenen Daten.
 
 \begin{table}[H]
@@ -157,7 +157,7 @@ Bei einer erhöhten Cache"=Größe, von 1000 auf 10000, zeigt sich auf den erste
 \autoref{tbl:measure-ojpa-active-bigger} ersichtlich ist. Der erste Aufruf entspricht der Laufzeit mit geringerer 
 Cache"=Größe, aber schon die Anfragen an die Datenbank gehen drastisch zurück. Bei den weiteren Aufrufen werden im 
 Schnitt nun nur noch 6 Anfragen pro Seitenaufruf an die Datenbank gestellt, wodurch die Laufzeit im Schnitt nochmal 
-um 100 ms beschleunigt werden konnte.
+um 100 ms beschleunigt werden kann.
 
 \begin{table}[H]
     \centering
@@ -254,7 +254,7 @@ aktiviert und muss explizit deaktiviert werden, wenn dies nicht gewünscht ist.
 Cache"=Manager aktiviert werden, dieser kann entweder durch Code programmiert werden oder über eine Konfiguration
 in der \textit{ehcache.xml}.
 
-Anhand der Auswertung von \ref{tbl:measure-ehcache-active} sieht man, dass der Ehcache einen starke Performance
+Anhand der Auswertung von \autoref{tbl:measure-ehcache-active} sieht man, dass der Ehcache eine starke Performance
 Verbesserung aufbringt. Über die Performance"=Statistik"=Webseite kann beobachtet werden, dass bei gleichen Aufrufen
 der Webseite nur die Treffer in Cache steigen, aber die Misses nicht. Ebenfalls erhöht sich die Anzahl der Objekte
 im Cache nicht. Zusätzlich steigt in diesem Fall der Speicherverbrauch nur gering bis gar nicht. Des Weiteren zeigt sich,
@@ -289,14 +289,14 @@ benötigt.
 \label{sec:performance-investigation-application:caching-ejb}
 
 Die Cache"=Einstellungen des \ac{EJB} sind in der Admin-Oberfläche des Payara-Servers zu erreichen. Unter dem Punkt
-Configurations $\Rightarrow$ server"=config $\Rightarrow$ \ac{EJB} Container werden zum einen die minimalen und maximalen 
+Configurations $\Rightarrow$ server"=config $\Rightarrow$ \ac{EJB} Container wird zum einen die minimalen und maximalen 
-Größen des Pools definiert werden. Zum anderen wird an dieser Stelle die maximale Größe des Caches und die Größe der
+Größen des Pools definiert. Zum anderen wird an dieser Stelle die maximale Größe des Caches und die Größe der
 Erweiterung definiert.
 
 Anhand der Auswertung der \autoref{tbl:measure-ejb-cache-active} ist ersichtlich, dass der \ac{EJB}"=Cache keine
 Auswirkung auf die Performance hat. Ebenso ist es ersichtlich, dass die Anzahl der Datenbankabfragen nicht reduziert
-wurde. Dies ist dadurch zu erklären, dass im \ac{EJB} die Provider gelagert werden, die über Dependency Injection
+werden. Dies ist dadurch zu erklären, dass im \ac{EJB} die Provider gelagert sind, die über Dependency Injection
-dem Controller bereitgestellt werden. Die Objekte selbst werden nicht im \ac{EJB}"=Cache hinterlegt.
+dem Controller bereitgestellt werden. Die Objekte selbst sind nicht im \ac{EJB}"=Cache hinterlegt.
 
 % document, documentaddresseeperson, first/last, documentcoauthorperson, count und documentfacsimile
 \begin{table}[H]
@@ -323,9 +323,11 @@ dem Controller bereitgestellt werden. Die Objekte selbst werden nicht im \ac{EJB
 \section{Abfragen JPQL}
 \label{sec:performance-investigation-application:query-jpql}
 
-Für die \ac{JPQL} wird ein \ac{SQL} ähnlicher Syntax verwendet, um die Abfragen an die Datenbank durchzuführen. Für die
+Für die \ac{JPQL} wird ein \ac{SQL} ähnlicher Syntax verwendet, um die Abfragen an die Datenbank durchzuführen. Der 
-Dokumentenliste wird der Code aus \autoref{lst:jpql-document-list-jpql} verwendet. Die Namen mit vorangestellten 
+nachfolgende Code für die Dokumentenliste, welche in \ac{JPQL} geschrieben ist, ist aus dem DFG"=Projekt 
-Doppelpunkt sind Übergabevariablen.
+\citep{DFGProje43:online} entnommen. Das \autoref{lst:jpql-document-list-jpql} zeigt den \ac{JPQL}"=Code welcher unter
+dem Namen \textit{Document.""findAll} hinterlegt ist, um die Daten aus dem \textit{PostgreSQL}"=Server zu ermitteln. 
+Die enthaltenen Namen mit vorangestellten Doppelpunkt sind Übergabevariablen, um die Auswahl einzuschränken.
 
 \begin{lstlisting}[language=Java,caption={JPQL Dokumentenliste},label=lst:jpql-document-list-jpql]
 SELECT DISTINCT d FROM Document d
@@ -337,9 +339,9 @@ AND    d.isPublishedInDb = :published
 ORDER  BY d.documentId ASC
 \end{lstlisting}
 
-In dem dazugehörigen Code am Server wird der JPQL-Code als NamedQuery hinterlegt und über den Name 
+Der dazugehörige Code im Server ist in \autoref{lst:jpql-document-list} zu finden und zeigt wie die benannte Anfrage 
-\textit{Document.""findAll} referenziert. Eine Veränderung der Abfrage ist hier leider nicht möglich, wie man im Code 
+aufgerufen und die ermittelt Daten übernimmt. Zusätzlich wird an dieser Stelle die Parameter versorgt, die Grenzwerte
-aus \autoref{lst:jpql-document-list} sehen kann.
+der Paginierung und die Hints hinterlegt.
 
 \begin{lstlisting}[language=Java,caption={Java JPQL Dokumentenliste},label=lst:jpql-document-list]
 List<Document> myResultList = createNamedTypedQuery("Document.findAll")
@@ -356,7 +358,7 @@ if(myResultList != null && !myResultList.isEmpty()) {
 }
 \end{lstlisting}
 
-Da dieser Code direkt so aus dem Projekt kommt, wird hierfür keine gesonderte Zeitmessung durchgeführt, da diese der
+Da dieser Code direkt so aus dem Projekt stammt, wird hierfür keine gesonderte Zeitmessung durchgeführt, da diese der
 Messung aus \autoref{tbl:measure-without-cache} entspricht.
 
 Für die Optimierung wurden noch zusätzlich die Hints \texttt{openjpa.""hint.""OptimizeResultCount},
@@ -390,12 +392,13 @@ wurde fast geviertelt. Dies zeigt, dass die einzelnen Aufrufe je Dokument aufwen
 der abhängigen Daten und das zusammensetzen in der OpenJPA-Schicht.
 
 Der letzte Hint \texttt{openjpa.""FetchPlan.""MaxFetchDepth} schränkt die rekursive Tiefe ein, für die abhängige
-Objekte mitgeladen werden. Lediglich auf Grund fehlender Datenbestände wird die Abfrage beschleunigt.
+Objekte mitgeladen werden. Lediglich auf Grund fehlender Datenbestände wird die Abfrage beschleunigt und ist daher 
+in diesem Fall nicht zu verwenden.
 
 \section{Abfragen Criteria API}
 \label{sec:performance-investigation-application:query-criteria-api}
 
-Für die Criteria API wird die Abfrage nicht in einem \ac{SQL}"=Dialekt beschreiben, hierbei werden über Attribute die
+Für die Criteria API wird die Abfrage nicht in einem \ac{SQL}"=Dialekt beschrieben, hierbei werden über Attribute die
 Verlinkung zur Datenbank durchgeführt. An der Klasse selbst wird der Tabellenname definiert und an den Attributen die
 Spaltennamen. Um die Anfrage durchzuführen, muss nun nur noch die Datenklasse angegeben und mit den Parametern
 versorgt werden, wie es in \autoref{lst:criteria-api} gezeigt wird. 
@@ -451,7 +454,7 @@ Abfragen in den Java-Objekten fast identisch sind. In der Datenbank sind die Anf
     \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 
 Implementierungen ohne Bedenken gegeneinander ausgetauscht werden, und die verwendet werden, die für den Anwendungsfall
 einfacher umzusetzen ist.
 
@@ -614,10 +617,10 @@ vorhanden Elemente, welche die Liste der Dokumente anzeigt, kopiert und auf die
 Wie in \autoref{tbl:measure-materialized-view} zu sehen ist, bringt die Verwendung der \textit{Materialized View} eine 
 Verbesserung in verschiedenen Punkten. Zum einen ist eine Verbesserung der Aufrufzeiten zu erkennen, zum anderen 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 sechs an die Datenbank gestellt werden, da die Einzelabfragen für die Adressen der 
+nur noch vier statt der sechs Abfragen an die Datenbank gestellt werden, da die Einzelabfragen für die Adressen der 
 Personen und der Koautoren komplett entfallen.
 
-Nach einer weiteren Untersuchung des Quellcodes wird festgestellt, dass bei jeder Anfrage die gleiche Bedingungen
+Nach einer weiteren Untersuchung des Quellcodes wird festgestellt, dass bei jeder Anfrage die gleichen Bedingungen
 benötigt werden. Da die Sicht nun explizit für diese Anfrage geschaffen ist, werden die Bedingungen nun direkt in die 
 Sicht mit integriert. Dies bedeutet eine Erweiterung der Sicht aus \autoref{lst:sql-materialized-view} um
 \autoref{lst:sql-materialized-view-ext} und das Entfernen der Parameter aus dem \ac{SQL}"=Anfragen im Java"=Code.
@@ -627,7 +630,7 @@ WHERE d.validuntil > NOW()
 AND   d.ispublishedindb = true;
 \end{lstlisting}
 
-Nach dem Anpassungen haben sich dann die Werte aus \autoref{tbl:measure-materialized-view-ext} ergeben. Diese Werte
+Nach den Anpassungen haben sich dann die Werte aus \autoref{tbl:measure-materialized-view-ext} ergeben. Diese Werte
 zeigen nur minimale Unterschiede in den Zeiten, diese sind auf Messtoleranzen zurückzuführen.
 
 \begin{table}[H]
@@ -795,10 +798,10 @@ sehr einfach verifiziert werden. Damit wird die Verwendung von \textit{Seq Scan}
 von \textit{Index Scan}.
 
 Die beste Optimierung hierbei ist, die Menge der Datensätze so früh wie möglich einzuschränken. Da die Verwendung von
-\texttt{order by} innerhalb eines Sub"=Selects nicht erlaubt ist, verwenden wir hierfür eine \textit{Common Table 
+\texttt{order by} innerhalb eines Sub"=Selects nicht erlaubt ist, wird hierfür eine \textit{Common Table Expression}
-Expression}, wie es in \autoref{lst:explain-optimize-cte} zu sehen ist. Zusätzlich wurde noch ein Index auf der 
+verwendet, wie es in \autoref{lst:explain-optimize-cte} zu sehen ist. Zusätzlich wurde noch ein Index auf der 
 \textit{document}"=Tabelle für die Spalten der Bedingung und der Sortierung gesetzt, wie in
-\autoref{lst:explain-optimize-cte-idx} zur sehen, damit in der \textit{Common Table Expression} nur der Index verwendet
+\autoref{lst:explain-optimize-cte-idx} zu sehen, damit in der \textit{Common Table Expression} nur der Index verwendet
 werden kann und kein zusätzlicher Zugriff in die Tabelle notwendig ist.
 
 \begin{lstlisting}[language=SQL,caption={Optimierung mit Common Table Expression},label=lst:explain-optimize-cte]
@@ -822,7 +825,7 @@ create index idx_document_with_stmt on document using btree
     , startday desc, id );
 \end{lstlisting}
 
-Mit diesen Umstellungen erkennt man, dass die Kosten entsprechend gefallen sind. Ebenfalls konnten die Laufzeit um
+Mit diesen Umstellungen erkennt man, dass die Kosten entsprechend gefallen sind. Ebenfalls konnte die Laufzeit um
 mehr als den Faktor drei reduziert werden. Die Optimierung ist in \autoref{fig:explain-visualize-with} sehr deutlich 
 an den dünneren Verbindungslinien zwischen den Knoten und der Umstellung von einigen \textit{Seq Scan} zu 
 \textit{Index Scan} ersichtlich. Zeitgleich ist auch der teure \textit{HashAggregate} nicht mehr im Abfrageplan 
@@ -839,7 +842,7 @@ mehr möglich ist, da durch die definierten Indexe bei den aktuell möglichen So
 \textit{Index Scan} verwendet wird. Dies ist durch eine Überprüfung der Abfragepläne beweisbar, für diesen Fall wird 
 die Abfrage aus \autoref{lst:explain-search-document} verwendet.
 
-\begin{lstlisting}[language=SQL,caption={xxxl},label=lst:explain-search-document]
+\begin{lstlisting}[language=SQL,caption={Untersuchung searchdocument},label=lst:explain-search-document]
 explain (analyze)
 select sd.id, documentid, datetype, startyear, startmonth, startday
     , startdatestatus , endyear, endmonth, endday, enddatestatus
@@ -855,9 +858,10 @@ Ausgabe mit dem erstellten Index. Vor der zweiten Ausgabe wurde dieser Index dea
 sehen, dass bei der Verwendung des Index weniger Operation notwendig sind und damit auch die teure Sortierung 
 eingespart werden konnte. Dies liegt daran, dass der Index entsprechend des Sortierkriterien definiert wurde und
 somit ist es möglich, direkt in dem Index die Elemente in der richtigen Reihenfolge zu ermitteln.
-Somit ist durch den Index der schnellstmögliche Zugriff gegeben.
+Somit ist durch den Index der schnellstmögliche Zugriff gegeben. Bei einem \textit{Seq Scan} ist die Ausgabe immer eine
+unsortierte Liste und benötigt daher im Nachgang die zusätzliche Sortierung.
 
-\begin{lstlisting}[basicstyle=\scriptsize,caption={aa},label=lst:explain-search-document-output]
+\begin{lstlisting}[basicstyle=\scriptsize,caption={Abfrageplan searchdocument},label=lst:explain-search-document-output]
 Limit  (cost=0.28..144.92 rows=400 width=948) (actual time=0.035..0.660 rows=400 loops=1)
   ->  Index Scan Backward using idx_searchdocument_startdate on searchdocument sd (cost=0.28..1911.30 rows=5285 width=948) (actual time=0.033..0.593 rows=400 loops=1)
 Planning Time: 0.199 ms

chapters/thesis/chapter06.tex

@@ -11,9 +11,10 @@ Es wurden die Konfigurationen der Caches von OpenJPA, \ac{JPA} und \ac{EJB} akti
 Caches, bei denen eine Größe angebbar ist, wurde zusätzlich mit der Anzahl variiert, um zu ermitteln, in welchem Umfang
 sich diese auswirken. Des Weiteren wird die Art der Programmierung für die Abfragen betrachtet, ob signifikante
 Unterschiede in der Performance und der Abarbeitung erkennbar sind. Als weiteren Punkt werden die Abfragen an die 
-Datenbank untersucht, um zu ermitteln, ob diese durch Umstellung verbessert werden können. Abschließend werden die 
+Datenbank untersucht, um zu ermitteln, ob diese durch Umstellung verbessert werden können. Danach werden die 
 \textit{Materialized View} verwendet, um zu ermitteln, ob durch einen vorverdichteten und aufbereiteten Datenbestand 
-die Abfragen beschleunigt werden können.
+die Abfragen beschleunigt werden können. Abschließend werden die Abfragen in der Datenbank betrachtet und auf ihre
+Optimierungspotentiale hin untersucht.
 
 \section{Nutzerumfrage}
 \label{sec:evaluation:user-survey}
@@ -23,7 +24,7 @@ Personen zur Verfügung stehen, ist dies nicht zielführend. Daher ist die einzi
 wurde, ein rein technischer Ansatz.
 
 \section{Umgestalten der Datenbanktabellen}
-\label{sec:evaluation:new-table}
+\label{sec:evaluation:new-table} 
 
 Hierfür wurde die aktuelle Datenstruktur untersucht, um zu überprüfen, ob eine Umgestaltung der Tabelle eine Verbesserung
 bringt. Die typische Optimierung ist die Normalisierung der Tabellenstruktur. Die Tabellenstruktur ist aktuell
@@ -31,7 +32,7 @@ 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.
 Dies ist in diesem Fall nicht anwendbar, da nicht nur 1:n Beziehungen vorhanden sind, sondern auch auch n:m Beziehungen.
-Dadurch würde sich die Anzahl der Dokumentenliste erhöhen. 
+Dadurch würde sich fälschlicherweise die Anzahl der Dokumentenliste erhöhen. 
 
 \section{Statische Webseiten}
 \label{sec:evaluation:static-website}
@@ -81,7 +82,7 @@ hoch aus. Sobald bei den Anfragen aber häufig die zu ermittelnden Objekte sich
 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 betrachtet werden.
+den Speicherbedarf noch weiter erhöht, da diese Objekte nicht in die Zählung der Cache"=Objekte miteinfliesen.
 Als größten Nachteil des Caches ist zu nennen, dass die notwendige Speichermenge 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 entleert wird. Gerade bei kleiner dimensionierten Servern stellt dies ein
@@ -114,7 +115,7 @@ Dadurch ist dieser Cache für eine Performance"=Verbesserung in dem Fall der Dok
 
 Mit dem Ehcache konnte eine Verbesserung in der Performance erzielt werden. Im Vergleich zum Cache von OpenJPA ist
 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
+keine Anpassung benötigt, um eine gute Performance zu erreichen. 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.
@@ -147,7 +148,7 @@ Abfragen kein Unterschied festgestellt werden. Die Abfragen der beiden Systeme s
 identisch. Auch in der Übertragung der Daten aus der Datenbank in die Java"=Objekte konnte kein 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
+Ebenfalls sind die Möglichkeiten über der Optimierung durch Hints identisch. In beiden Fällen haben die meisten Hints
 keinen 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.
@@ -159,7 +160,7 @@ Datenbank gestellt wird, sondern es werden alle Koautoren für die ermittelten D
 Zuordnung der Koautoren zu dem Dokument wird dann nun im Framework und nicht mehr durch die Datenbank durchgeführt.
 Diese Abarbeitung reduziert viele einzelne Abfragen und somit auch den entsprechend Overhead im Framework.
 
-Folglich ist die Entscheidung der Technik für die Performance irrelevant und es kann das genutzt werden, was für
+Folglich ist die Entscheidung der Technik für die Performance irrelevant und es kann das genutzt werden, was für den
 jeweiligen Einsatzzweck besser beziehungsweise einfacher zu programmieren ist. Das Setzen der richtigen Hints wiederrum
 ist in beiden Fällen äußerst wichtig. Explizit bei 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 
@@ -196,7 +197,7 @@ optimiert werden. Die Wandlung der Daten in \textit{\ac{HTML}}"=Objekte ist eine
 schwächeren Clients in kurzer Zeit durchführbar.
 
 Als weiteren Punkt ist anzumerken, dass der Speicherbedarf des Webserver relativ konstant bleibt, ohne dass ein Cache 
-verwendet wird. Der größte Unterschied zur Standardimplementierung ist die Verwendung von eigenen Codes, um die Objekte
+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 Probleme in der Speicherverwaltung der Objekte im OpenJPA"=Framework existieren.
 
@@ -229,14 +230,14 @@ ist es laut Berechnung kostengünstiger mit einem \textit{Seq Scan}, was einem k
 entspricht, zu arbeiten.
 
 Um dies zu optimieren, wurde über eine \textit{Common Table Expression} zuerst die eingeschränkten Datenzeilen 
-ermittelt, dieser mit der Haupttabelle verknüpft und nun die anderen Tabellen dazugenommen. Hierdurch konnte die 
+ermittelt, diese mit der Haupttabelle verknüpft und nun die anderen Tabellen dazugenommen. Hierdurch konnte die 
 Zeilenanzahl während der Verarbeitung enorm verringert werden, wodurch einige der Verknüpfungen auf Indexzugriffe 
 umgestellt wurden. Durch die Umstellung konnte die Abfragezeit um mehr als das dreifache reduziert werden.
 
 Mit dieser Art der Umstellung können Abfragen optimiert werden, die für das Paging verwendet werden und die Abfrage aus
 mehrere Tabellen besteht. Das Wichtigste hierbei ist, dass die Bedingungen und die Sortierkriterien auf der 
 Haupttabelle arbeiten. Wenn dem nicht so ist, müssen Joins in die \textit{Common Table Expression} mit aufgenommen 
-werden und damit funktioniert die Reduzierung der Datensätze nicht mehr. Bei der Selektion einer Tabelle hat diese Art 
+werden und damit funktioniert die Reduzierung der Datensätze nicht mehr so effizient. Bei der Selektion einer Tabelle hat diese Art 
 der Optimierung keine Auswirkung, hier hilft nur das geschickte Setzen von Indexen auf die Tabelle, welche die
 Bedingungen und die Sortierkriterien beinhalten. Dies wurde mit der Untersuchung der Abfrage auf die 
 \textit{Materialized View} bestätigt.

chapters/thesis/chapter07.tex

@@ -9,7 +9,7 @@
 
 Die Untersuchungen am Beispiel des Wedekind"=Projektes zeigen, dass mehrere Optimierungsmöglichkeiten in den 
 Briefeditionen 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 
+die Optimierung implementiert, untersucht und jeweils mit der Ausgangsmessung verglichen. Für die Messung wurden 
 Skripte erstellt, welche auf dem gleichen Computer wie der Webserver und der Datenbankserver laufen, damit diese auch
 vergleichbar bleiben und externe Einflussfaktoren minimiert werden.
 
@@ -24,7 +24,7 @@ Webseite wurden auf Grund von technischen Einschränkungen nicht weiterverfolgt.
 
 Bei den Caches sind der Query"=Cache und der \ac{EJB}"=Cache nicht für die Optimierung verwendbar. Der Query"=Cache wird
 von OpenJPA nur verwendet, wenn die Abfrage keine Parameter besitzt, welche in der Dokumentliste verwendet werden
-mussten. Im \ac{EJB}"=Cache werden nicht die Objekt, sondern die Provider gespeichert, wodurch hier keine Auswirkung auf die
+müssen. Im \ac{EJB}"=Cache werden nicht die Objekt, sondern die Provider gespeichert, wodurch hier keine Auswirkung auf die
 Performance festgestellt werden konnte.
 
 Anders sieht es bei dem OpenJPA"=Cache aus, dieser hat direkten Einfluss auf die Performance der Ermittlung der Daten 
@@ -47,7 +47,7 @@ durch die Umstellung der Ermittlung der unterlagerten Daten durch Hints eine Opt
 bezweckt, dass die unterlagerten Daten nicht einzeln für jede Zeile ermittelt werden, 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 eine gute Optimierung
+Mit der Übernahme der \textit{Materialized View} aus dem Wedekind"=Projekt kann eine gute Optimierung
 beobachtet werden. Dies ist auf die einfachere Abfrage, die Reduzierung der Abfrage an den Datenbankserver und dass
 die Objekte im eigenen Code erstellt werden zurückzuführen und nicht auf 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.
@@ -56,13 +56,14 @@ Auf Grund dessen wurde das Parsen der Json"=Daten auf den Client verschoben, was
 Für die Optimierung der Abfragen wurde die Hauptabfrage betrachtet. Bei dieser konnte anhand der visuellen Darstellung
 das Problem gut identifiziert werden. Durch die Verwendung einer \textit{Common Table Expression} wurde die Anzahl
 der Datensätze direkt am Anfang auf die angefragte Menge reduziert, wodurch die Anzahl der zu betrachteten Datensätze 
-für die weiteren Verlinkungen enorm reduziert wurde. Somit konnte der Datenbankserver bei diesen Verlinkungen auf Indexe 
+für die weiteren Verlinkungen enorm reduziert wird. Somit konnte der Datenbankserver bei diesen Verlinkungen auf Indexe 
-zugreifen und damit die Abfragen zusätzlich beschleunigen.
+zurückgreifen 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 dass das größte Optimierungspotential in dem \ac{ORM} liegt. Welche der %dass oder das
+Briefeditionen zu beschleunigen und dass das größte Optimierungspotential in dem \ac{ORM} liegt. Die Umstellung auf 
-Optimierungen verwendet werden, liegt an der Komplexität der Abfrage und der bereitgestellten Ressourcen 
+eine \textit{Materialized View} ist eine sinnvolle Wahl, wenn die Abfrage der Daten komplexer ist oder aus mehreren 
-des Servers.
+n:m"=Beziehungen besteht. Bei der Verwendung eines Caches sollte darauf geachtet werden, dass die notwendigen
+Ressourcen am Server bereitgestellt werden können und es wird empfohlen auf den Ehcache umzustellen.
 
 \section{Ausblick}
 \label{sec:summary_and_outlook:outlook}
@@ -77,6 +78,6 @@ werden. Bei den Umstellungen der Abfragen ist die größte Stärke, wenn die Anz
 könnte.
 
 Dadurch zeigt sich, dass die Untersuchung auf Ebene der \ac{ORM} noch nicht abgeschlossen ist. Weitere Untersuchungen
-von anderen \ac{ORM} könnten wie in \ref{sec:evaluation:materialized-view} angedeutet das Speicherproblem lösen, 
+von anderen \ac{ORM} könnten wie in \autoref{sec:evaluation:materialized-view} angedeutet das Speicherproblem lösen, 
 sowie eine generelle Optimierung der Webseite zur Folge haben. Eine eigenständige Implementierung eines einfachen 
-\ac{ORM} wäre auch in Betracht zu ziehen, solange sich die Komplexität der Daten"=Struktur nicht erhöht.
+\ac{ORM} wäre auch in Betracht zu ziehen, solange sich die Komplexität der Daten"=Struktur nicht erhöht.

expose-ref.bib

@@ -90,6 +90,15 @@
   urldate = {2024-09-20}
 },
 
+@online{DFGProje43:online,
+  author = {DFG-Projekt},
+  title = {DFG-Projekt: Edition der Korrespondenz Frank Wedekinds als Online-Volltextdatenbank - FernUniversität in Hagen},
+  url = {https://www.fernuni-hagen.de/dbis/forschung/wedekind.shtml},
+  month = {},
+  year = {},
+  urldate = {2024-09-28}
+},
+
 @online{Dokument53:online,
   author = {},
   title = {Dokumentenliste mit Native Query und Materialized View (b1f4c93d) · Commits · Wedekind / briefdb 2.0 · GitLab},