diff --git a/chapters/thesis/chapter02.tex b/chapters/thesis/chapter02.tex index 87e41d1..fa05590 100644 --- a/chapters/thesis/chapter02.tex +++ b/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 diff --git a/chapters/thesis/chapter03.tex b/chapters/thesis/chapter03.tex index 6f0a783..8f90f9a 100644 --- a/chapters/thesis/chapter03.tex +++ b/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. diff --git a/chapters/thesis/chapter04.tex b/chapters/thesis/chapter04.tex index 361d553..cf14135 100644 --- a/chapters/thesis/chapter04.tex +++ b/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. diff --git a/chapters/thesis/chapter05.tex b/chapters/thesis/chapter05.tex index 8e77760..d07720c 100644 --- a/chapters/thesis/chapter05.tex +++ b/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) diff --git a/chapters/thesis/chapter06.tex b/chapters/thesis/chapter06.tex index 162a8c0..85d4fe5 100644 --- a/chapters/thesis/chapter06.tex +++ b/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. diff --git a/chapters/thesis/chapter07.tex b/chapters/thesis/chapter07.tex index 05fb04a..3c4a645 100644 --- a/chapters/thesis/chapter07.tex +++ b/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. diff --git a/thesis.pdf b/thesis.pdf index b6f25dc..dfc466b 100644 Binary files a/thesis.pdf and b/thesis.pdf differ