Daily CheckIn

chapters/thesis/chapter02.tex

@@ -11,7 +11,7 @@ geht durch mehrere Schichten des Server"=System bis die Antwort an den Client zu
 Es wird ab hier von einem \textit{GlassFish}"=Server die Rede sein. 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 neuesten Features unterstützt. Der \textit{Payara}"=Server ist aus dessen Quellcode entstanden
-und ist für Produktivumgebungen gedacht, da dieser mit regelmäßigen Aktualisierungen versorgt wird. Im folgenden Text
+und ist für Produktivumgebungen gedacht, da dieser mit regelmäßigen Aktualisierungen versorgt wird. In diesem und dem folgenden Kapitel
 wird für beide Anwendungen der Begriff \textit{GlassFish} verwendet.
 
 Angefangen bei der Anfrage die über den Webbrowser an den Server gestellt wird und vom \textit{GlassFish}"=Server

chapters/thesis/chapter03.tex

@@ -34,9 +34,9 @@ Für die Wartungsaufgaben wie VACUUM oder dem Erstellen von Indexen wird die Beg
 \texttt{maintenance\_work\_mem} gesetzt. Dieser Wert sollte 5\% des verfügbaren Arbeitsspeicher entsprechen und größer
 als \texttt{work\_mem} sein.
 
-Nachfolgend wird mit dem Systemtools, wie den Konsolenanwendungen \textit{htop} und \textit{free}, die Auslastung des Servers 
+Nachfolgend wird mit den 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. %TODO wichtigsten?
+die wichtigsten Faktoren zur Bewertung.
 
 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 
@@ -124,8 +124,8 @@ und dessen Ausführungszeit ermittelt.
 
 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 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 damit eine Reduzierung der Abfragedauern erreichen.
+diese viel schneller abgefragt werden können. Zusätzlich werden die \textit{Cached queries} überprüft, ob diese eine Verbesserung 
+der Performance ergeben und damit eine Reduzierung der Abfragedauern erreichen.
 
 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.

chapters/thesis/chapter04.tex

@@ -48,7 +48,7 @@ in die Log"=Datei eingetragen. Durch die Kennung können die Zeiten im Nachgang
 ausgewertet werden.
 
 Zusätzlich wird noch eine Implementierung der zugehörigen Factory"=Klasse \texttt{ViewDeclarationLanguageFactory}
-benötigt. Durch diese Factory"=Klasse wird der eigentlichen Wrapper mit der Performance-Messung in die Bearbeitungsschicht
+benötigt. Durch diese Factory"=Klasse wird der eigentlichen Wrapper mit der Performance"=Messung in die Bearbeitungsschicht
 eingehängt. Diese Implementierung wird dann noch in der \texttt{faces-config.xml} eingetragen, wie das in
 \autoref{lst:activate-factory} aufgezeigt wird, damit die Factory durch das System aufgerufen wird.
 
@@ -78,7 +78,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 weiteren Einstellungen sind so
-gesetzt, dass nicht unnötige Abfragen für die spätere Auswertung mit \textit{pgBadger} protokolliert werden.
+gesetzt, dass nur notwendige 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
 nicht ausreicht und die Zwischenergebnisse ausgelagert werden müssen.
@@ -102,7 +102,7 @@ log_timezone = 'Europe/Berlin'
 \section{Prüfung von Abfragen}
 \label{sec:performance-checking:sql-query-checking}
 
-Das Untersuchen der protokollierten Abfragen auf Performance Optimierungen ist ein weiterer Bestandteil dieser Arbeit. 
+Das Untersuchen der protokollierten Abfragen auf Performance"=Optimierungen ist ein weiterer Bestandteil dieser Arbeit. 
 Das Schlüsselwort \texttt{EXPLAIN} ist im PostgreSQL vorhanden, um den Abfrageplan einer Abfrage zu ermitteln und
 darzustellen, um diese anschließend zu untersuchen. Der Abfrageplan ist als Baum dargestellt, bei welchem die Knoten die 
 unterschiedlichen Zugriffsarten darstellen. Die Verbindung der Knoten und der Aufbau zeigt die Operationen, wie 
@@ -140,17 +140,17 @@ Vergleichsoperation auf die Tabellenspalte zugegriffen wird.
 Um größere und aufwendigere Abfragen zu optimieren, bietet der PostgreSQL noch die Möglichkeit von 
 \textit{Materialized View}. Diese sind sehr ähnlich zu den Sichten, zusätzlich werden aber die Ergebnisse in einer 
 tabellenähnlichen Form abgespeichert, somit sind die Zugriff auf diese Daten häufig performanter als die eigentliche Abfrage. 
-Daher muss abgewägt werden, ob die Performance-Verbesserung trotz der zusätzlichen Aktualisierung des Datenbestandes 
+Daher muss abgewägt werden, ob die Performance"=Verbesserung trotz der zusätzlichen Aktualisierung des Datenbestandes 
 als sinnvoll erachtet werden kann.
 
-Zusätzlich kann über die Systemtabelle \texttt{pg\_statistic} oder die lesbarere Systemsicht \texttt{pg\_stats} die
+Zusätzlich können über die Systemtabelle \texttt{pg\_statistic} oder die lesbarere Systemsicht \texttt{pg\_stats} die
 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.
 
-Durch das Kommando \texttt{CREATE STATISTICS} können diese Informationen erweitert werden, um das erstellen des Abfrageplans
+Durch das Kommando \texttt{CREATE STATISTICS} können diese Informationen erweitert werden, um das Erstellen des Abfrageplans
 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

@@ -16,8 +16,8 @@ gedauert hat. Die weiteren Aufrufe benötigen im Durchschnitt noch 600 ms. Beim
 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 ist eine Erweiterung
-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 wird durch die
+des Test"=Scripts notwendig, um die aktuelle Speichernutzung des Payara"=Servers darzustellen und auszuwerten. Diese
+Auswertung zeigt, 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
@@ -68,10 +68,10 @@ konfigurierten Cache Einstellungen. Einige dieser Abfragen sind durch das Erstel
 \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, ist der Dienst und das Erstellen im Code für die weiteren Tests deaktiviert.
+benötigt werden, werden der Dienst und das Erstellen im Code für die weiteren Tests deaktiviert.
 
 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 
+PostgreSQL und den Payara"=Server ein Docker"=Container erzeugt und dieser limitiert. Die Konfiguration ist in 
 \autoref{ap:docker_config} beschrieben.
 
 Mit dem neuen Aufbau ergibt sich eine neue Messung. Für den Speicherbedarf wird nun nicht mehr der benutzte
@@ -156,7 +156,7 @@ wachsenden Speicherbedarfs nur nicht erklärt werden.
 Bei einer erhöhten Cache"=Größe, von 1000 auf 10000, zeigt sich auf den ersten Blick ein noch besseres Bild ab, wie in
 \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 
+Schnitt nun nur noch sechs Anfragen pro Seitenaufruf an die Datenbank gestellt, wodurch die Laufzeit im Schnitt nochmal 
 um 100 ms beschleunigt werden kann.
 
 \begin{table}[H]
@@ -289,8 +289,8 @@ 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 wird zum einen die minimalen und maximalen 
-Größen des Pools definiert. Zum anderen wird an dieser Stelle die maximale Größe des Caches und die Größe der
+Configurations $\Rightarrow$ server"=config $\Rightarrow$ \ac{EJB} Container werden zum einen die minimalen und maximalen 
+Größen des Pools definiert. Zum anderen werden 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
@@ -340,7 +340,7 @@ ORDER  BY d.documentId ASC
 \end{lstlisting}
 
 Der dazugehörige Code im Server ist in \autoref{lst:jpql-document-list} zu finden und zeigt wie die benannte Anfrage 
-aufgerufen und die ermittelt Daten übernimmt. Zusätzlich wird an dieser Stelle die Parameter versorgt, die Grenzwerte
+aufgerufen und die ermittelten Daten übernimmt. Zusätzlich werden an dieser Stelle die Parameter versorgt, die Grenzwerte
 der Paginierung und die Hints hinterlegt.
 
 \begin{lstlisting}[language=Java,caption={Java JPQL Dokumentenliste},label=lst:jpql-document-list]
@@ -358,7 +358,7 @@ if(myResultList != null && !myResultList.isEmpty()) {
 }
 \end{lstlisting}
 
-Da dieser Code direkt so aus dem Projekt stammt, wird hierfür keine gesonderte Zeitmessung durchgeführt, da diese der
+Da dieser Code direkt 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},
@@ -398,7 +398,7 @@ 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 beschrieben, hierbei werden über Attribute die
+Für die Criteria API wird die Abfrage nicht in einem \ac{SQL}"=Dialekt geschrieben, 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. 
@@ -454,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.
 
@@ -630,7 +630,7 @@ WHERE d.validuntil > NOW()
 AND   d.ispublishedindb = true;
 \end{lstlisting}
 
-Nach den Anpassungen haben sich dann die Werte aus \autoref{tbl:measure-materialized-view-ext} ergeben. Diese Werte
+Nach den Anpassungen haben sich 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]
@@ -799,8 +799,8 @@ 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, wird hierfür eine \textit{Common Table Expression}
-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
+verwendet, wie es in \autoref{lst:explain-optimize-cte} zu sehen ist. Zusätzlich wird noch ein Index auf die
+\textit{document}"=Tabelle für die Spalten der Bedingung und der Sortierung erstellt, wie in
 \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.
 
@@ -859,7 +859,7 @@ sehen, dass bei der Verwendung des Index weniger Operation notwendig sind und da
 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. Bei einem \textit{Seq Scan} ist die Ausgabe immer eine
-unsortierte Liste und benötigt daher im Nachgang die zusätzliche Sortierung.
+unsortierte Liste und benötigt daher im Nachgang eine zusätzliche Sortierung.
 
 \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)

chapters/thesis/chapter06.tex

@@ -32,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 fälschlicherweise die Anzahl der Dokumentenliste erhöhen. 
+Dadurch erhöht sich fälschlicherweise die Anzahl der Dokumentenliste. 
 
 \section{Statische Webseiten}
 \label{sec:evaluation:static-website}
@@ -148,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 durch Hints identisch. In beiden Fällen haben die meisten Hints
+Ebenfalls sind die Möglichkeiten der Optimierung durch die 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.
@@ -197,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 Code, um die Objekte
+verwendet wird. Der größte Unterschied zur Standardimplementierung ist die Verwendung von eigenen Codes, 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,15 +229,15 @@ sind. Für den PostgreSQL
 ist es laut Berechnung kostengünstiger mit einem \textit{Seq Scan}, was einem kompletten Durchlaufen der Tabelle 
 entspricht, zu arbeiten.
 
-Um dies zu optimieren, wurde über eine \textit{Common Table Expression} zuerst die eingeschränkten Datenzeilen 
-ermittelt, diese mit der Haupttabelle verknüpft und nun die anderen Tabellen dazugenommen. Hierdurch konnte die 
+Um dies zu optimieren, werden über eine \textit{Common Table Expression} zuerst die eingeschränkten Datenzeilen 
+ermittelt, diese mit der Haupttabelle verknüpft und anschließend die anderen Tabellen hinzugenommen. Hierdurch kann 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.
+umgestellt werden. Durch die Umstellung kann 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 so effizient. Bei der Selektion einer Tabelle hat diese Art 
+werden und damit funktioniert die Reduzierung der Datensätze weniger 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 
+Bedingungen und die Sortierkriterien beinhalten. Dies wird mit der Untersuchung der Abfrage auf die 
 \textit{Materialized View} bestätigt.

chapters/thesis/chapter07.tex

@@ -61,7 +61,7 @@ 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. Die Umstellung auf 
-eine \textit{Materialized View} ist eine sinnvolle Wahl, wenn die Abfrage der Daten komplexer ist oder aus mehreren 
+eine \textit{Materialized View} ist eine sinnvolle Wahl, wenn die Abfrage der Daten komplexer ausfällt oder aus mehreren 
 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.
 
@@ -80,4 +80,4 @@ 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 \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 ebenfalls in Betracht zu ziehen, solange sich die Komplexität der Daten"=Struktur nicht erhöht.