diff --git a/.vscode/settings.json b/.vscode/settings.json index 9d09d97..a72e57d 100644 --- a/.vscode/settings.json +++ b/.vscode/settings.json @@ -12,7 +12,6 @@ "Fouine", "freigeschalten", "Galster", - "Glassfish", "JPQL", "Konsolenanwendungen", "lesbarere", @@ -41,12 +40,14 @@ "Backmatter", "Classname", "Datasource", + "Deployen", "Frontmatter", "IntelliJ", "JNDI", "Laravel", "Latexmk", "Mainmatter", + "Mindest", "Nautsch", "Payara", "Poolname", @@ -56,6 +57,7 @@ "Servlet", "Symfony", "addresseeperson", + "adminpack", "adressee", "ajax", "american", @@ -88,6 +90,7 @@ "ferniunithesis", "firstname", "fmtutil", + "glassfish", "gpasswd", "hcap", "heapsort", @@ -95,18 +98,23 @@ "ispublishedindb", "javax", "jdbc", + "jdbcdriver", "jsonlog", "maxint", "modifiedat", "ngerman", + "onlineed", "openjpa", "pacman", "payara", "payra", "perfstat", "personid", + "postgres", "postgresql", "println", + "psql", + "rzungsverzeichnis", "searchdocument", "searchfulltext", "searchreference", @@ -123,6 +131,7 @@ "typeof", "validuntil", "wedekind", + "wedeojpa", "xsep" ], } \ No newline at end of file diff --git a/chapters/thesis/appendix06.tex b/chapters/thesis/appendix06.tex index cdbab25..e7723eb 100644 --- a/chapters/thesis/appendix06.tex +++ b/chapters/thesis/appendix06.tex @@ -10,7 +10,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. +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 \ref{lst:logger_factory_activate}, um die Factory durch das System aufrufen zu lassen. diff --git a/chapters/thesis/chapter01.tex b/chapters/thesis/chapter01.tex index 16c1594..bb0e4bf 100644 --- a/chapters/thesis/chapter01.tex +++ b/chapters/thesis/chapter01.tex @@ -30,7 +30,7 @@ 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. 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 +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 diff --git a/chapters/thesis/chapter02.tex b/chapters/thesis/chapter02.tex index d0b332a..87e41d1 100644 --- a/chapters/thesis/chapter02.tex +++ b/chapters/thesis/chapter02.tex @@ -8,13 +8,13 @@ dass jeder Wechsel einer Seite oder eine Suchanfrage als Web"=Request an den Ser geht durch mehrere Schichten des Server"=System bis die Antwort an den Client zurückgesendet wird, wie in \autoref{fig:webrequest} dargestellt. -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 +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 -wird der Begriff \textit{Glassfish} verwendet. +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 +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 \textit{\ac{JSF}} die Anfrage weitergeleitet und verarbeitet wird. In diesem wird die Darstellung der Webseite geladen und die Anfragen für den darzustellenden Datenbestand abgeschickt. @@ -29,7 +29,7 @@ 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}[!ht] +\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]}}, @@ -44,8 +44,8 @@ zu verringern. Um Anfragen, die den Zugriff auf die Festplatte benötigen effizi \node (EJB) [block,below of=JSF] {Enterprise Java Beans}; \node (JPA) [block,below of=EJB] {Java Persistance API}; \node (openJPA) [block, below of=JPA] {OpenJPA Cache}; - \node (fitGlassfish) [fit=(JSF) (EJB) (JPA) (openJPA)] {}; - \node [left] at (fitGlassfish.west) {Glassfish}; + \node (fitGlassFish) [fit=(JSF) (EJB) (JPA) (openJPA)] {}; + \node [left] at (fitGlassFish.west) {GlassFish}; \node (memoryBuffers) [block, below of=openJPA] {Memory Buffers}; \node (services) [block, right of=memoryBuffers, xshift=2cm] {Services}; @@ -53,7 +53,7 @@ zu verringern. Um Anfragen, die den Zugriff auf die Festplatte benötigen effizi \node (fitPostgreSQL) [fit=(memoryBuffers) (services) (database)] {}; \node [left] at (fitPostgreSQL.west) {PostgreSQL}; - \node (fitServer) [fit=(fitGlassfish) (fitPostgreSQL),inner xsep=5em] {}; + \node (fitServer) [fit=(fitGlassFish) (fitPostgreSQL),inner xsep=5em] {}; \node [left] at (fitServer.west) {Server}; \draw[lineArrow] (browser)--(JSF); @@ -68,11 +68,11 @@ zu verringern. Um Anfragen, die den Zugriff auf die Festplatte benötigen effizi \label{fig:webrequest} \end{figure} -\section{Glassfish - Enterprise Java Beans} +\section{GlassFish - Enterprise Java Beans} \label{sec:basics:ejb} In den Java"=EE"=Anwendungen wird der \textit{Persistenzkontext} für die Anfragen vom \textit{Application"=Server} -bereitgestellt. Hierfür werden \textit{Application"=Server} wie \textit{GlassFish} genutzt, um die Verwendung eines Pools +bereitgestellt. Hierfür werden \textit{Application"=Server} wie \textit{GlassFish} genutzt, um die Verwendung eines Pools % nicht eher die EJB innerhalb von glassfish von Datenbankverbindungen zu definieren \citep[68]{MüllerWehr2012}. Dadurch kann die Anzahl der Verbindungen geringer gehalten werden als die Anzahl der Benutzer, die an der Anwendung arbeiten. Zusätzlich werden die Transaktionen über \textit{\ac{SFSB}} gehandhabt, welche automatisch vor dem Aufruf erzeugt und danach wieder gelöscht @@ -81,7 +81,7 @@ Entities in den \textit{Persistenzkontext} geladen werden. Da dies häufig zu Sp \citep[79]{MüllerWehr2012} führen kann, muss hier darauf geachtet werden, nicht mehr benötigte Entities aus dem \textit{Persistenzkontext} zu lösen. -\section{Glassfish - Java Persistance API} +\section{GlassFish - Java Persistance API} \label{sec:basics:jpa} Die \textit{\ac{JPA}} wird als First"=Level"=Cache in Java"=EE"=Anwendung verwendet, hier nehmen die @@ -96,7 +96,7 @@ Eine Menge von Objekten wird als \textit{Persistenzkontext} bezeichnet. Solange überwacht, um diese am Abschluss mit der Datenbank zu synchronisieren. In der Literatur wird hierzu der Begriff \textit{Automatic Dirty Checking} verwendet \citep[61]{MüllerWehr2012}. -\section{Glassfish - OpenJPA Cache} +\section{GlassFish - OpenJPA Cache} \label{sec:basics:ojpac} Zusätzlich kann im \textit{\ac{JPA}} ebenfalls noch der \textit{Second Level Cache} (L2-Cache) aktiviert werden. Dieser steht diff --git a/chapters/thesis/chapter03.tex b/chapters/thesis/chapter03.tex index 1202b49..d08f622 100644 --- a/chapters/thesis/chapter03.tex +++ b/chapters/thesis/chapter03.tex @@ -3,7 +3,7 @@ \chapter{Konzept} \label{ch:concept} -Das folgende Kapitel enthält die im Rahmen dieser Arbeit entstandenen Konzepte, um die vorhanden Probleme zu +Das folgende Kapitel enthält die im Rahmen dieser Arbeit entstandenen Konzepte, um die vorhandenen Probleme zu identifizieren und mit entsprechenden Maßnahmen entgegenzusteuern. Hierbei werden zum einen die Konfigurationen der eingesetzten Software überprüft. Zum anderen werden die verschiedenen Schichten der entwickelten Software auf mögliche Optimierungen untersucht und bewertet. @@ -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 Produktivsysteme abgeglichen. Hierunter fallen die Einstellungen für die \texttt{shared\_buffers}, der bei einem Arbeitsspeicher von mehr als 1 GB -circa 25\% des Arbeitsspeicher besitzen sollte \cite{PostgresC20.4:2024}. +circa 25\% des Arbeitsspeichers besitzen sollte \cite{PostgresC20.4:2024}. Bei der Einstellung \texttt{temp\_buffers} geht es um den Zwischenspeicher für jede Verbindung, die bei der Verwendung von temporären Tabellen verwendet wird. Dieser Wert sollte auf dem Standardwert von 8 MB belassen werden und lediglich @@ -24,9 +24,9 @@ bei der Verwendung von großen temporären Tabellen verändert werden. Der Speicher, der für eine Abfrage verwendet werden darf, wird über die Konfiguration \texttt{work\_mem} gesteuert. Wenn der Speicher zu gering wird, werden die Zwischenergebnisse in temporäre Dateien ausgelagert. Der empfohlene Wert -berechnet sich aus \texttt{shared\_buffers} dividiert durch \texttt{max\_connections} \citep{ConfigTo12:online}. +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 %TODO: log_temp_files überschreitet den Rand +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 Dateien sollte der Grenzwert erhöht werden. Bei wenigen großen Dateien ist es ist sinnvoll den Wert so zu belassen. @@ -84,7 +84,7 @@ 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"=Server 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 @@ -115,7 +115,7 @@ welchen Umfang die Umstellungen eine Veränderung im Verhalten der Webseite bewi Bei den \ac{JSF} wird eine Zeitmessung einfügt, wofür eine \textit{Factory} benötigt wird. Diese wird in den Pipeline Prozess, der die Verarbeitung der Seiten steuert, eingebunden und erstellt die Klasse für die Messung. In dieser werden die Zeiten zum Ermitteln der Daten, das Zusammensetzen und das Rendern -der Sicht ermittelt. Die Zeiten werden in die Log"=Datei des \textit{Glassfish}"=Servers hinterlegt und durch das +der Sicht ermittelt. Die Zeiten werden in die Log"=Datei des \textit{GlassFish}"=Servers hinterlegt und durch das Skript ausgewertet. Somit ist es relativ leicht aufzuzeigen, an welcher Stelle die größte Verzögerung auftritt. Die Abfragen werden ebenfalls untersucht und mit verschiedenen Methoden optimiert. Hierfür werden zum einen auf native @@ -132,7 +132,7 @@ Wichtig hierbei ist, dass die Webseite immer vollständig gerendert vom Server a 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 -\textit{Glassfish}"=Servers vor und nach den Aufrufen ermittelt. Zum Schluss werden noch die Log"=Dateien 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. Um die Netzwerklatenz ignorieren zu können, wird das Skript auf dem gleichen Computer aufgerufen, auf dem der Webserver diff --git a/chapters/thesis/chapter04.tex b/chapters/thesis/chapter04.tex index 82d4345..e8cb418 100644 --- a/chapters/thesis/chapter04.tex +++ b/chapters/thesis/chapter04.tex @@ -150,7 +150,7 @@ durch das \texttt{ANALYZE} beziehungsweise \texttt{VACUUM ANALYZE} Kommando die 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 \texttt{CREATE STATISTICS} erweitert werden, für einen besseren %TODO texttt zeigt über den Rand +Diese Informationen können noch durch das Kommando \linebreak\texttt{CREATE STATISTICS} erweitert werden, für einen besseren Abfrageplan. 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 d91c17d..c6e0c39 100644 --- a/chapters/thesis/chapter05.tex +++ b/chapters/thesis/chapter05.tex @@ -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{GlassFish}"=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. @@ -44,7 +44,7 @@ Ebenfalls sieht man eindeutig, dass die Anzahl der Anfragen nach dem ersten Aufr Der Speicherbedarf steigt relativ gleichmässig, was nicht recht ins Bild passt, da hier keine Objekte im Cache gehalten werden sollten. -\begin{table}[!h] +\begin{table}[H] \centering \begin{tabular}{|r|r|r|r|r|r|r|r|} \hline @@ -88,7 +88,7 @@ Zusätzlich wird die Zeit des Rendern der Sicht gemessen. Die erste Messung erfa notwendig benötigt wird. Diese Zeit wird unterteilt in die Messungen 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] +\begin{table}[H] \centering \resizebox{\textwidth}{!}{ \begin{tabular}{|r|r|r|r|r|r|r|r|r|r|r|r|r|r|r|} @@ -132,7 +132,7 @@ Cache. Alle nachfolgenden Aufrufe wiederrum sind um 100ms schneller in der Verar Anfragen an die Datenbank kann der Rückgang der Anfragen sehr gut gesehen werden. Aktuell kann die Verringerung des wachsenden Speicherbedarfs nur nicht erklärt werden. -\begin{table}[h!] +\begin{table}[H] \centering \resizebox{\textwidth}{!}{ \begin{tabular}{|r|r|r|r|r|r|r|r|r|r|r|r|r|r|r|} @@ -159,7 +159,7 @@ Cache"=Größe, aber schon die Anfragen an die Datenbank gehen drastisch zurück Schnitt nun nur noch 6 Anfragen pro Seitenaufruf an die Datenbank gestellt, wodurch die Laufzeit im Schnitt nochmal um 100 ms beschleunigt werden konnte. -\begin{table}[!ht] +\begin{table}[H] \centering \resizebox{\textwidth}{!}{ \begin{tabular}{|r|r|r|r|r|r|r|r|r|r|r|r|r|r|r|} @@ -185,7 +185,7 @@ die \textit{SoftReference} nicht das Problem für den steigenden Arbeitsspeicher \autoref{tbl:measure-ojpa-active-bigger-no-softref} ersichtlich. % document, documentaddresseeperson, first/last, documentcoauthorperson, count und documentfacsimile -\begin{table}[h!] +\begin{table}[H] \centering \resizebox{\textwidth}{!}{ \begin{tabular}{|r|r|r|r|r|r|r|r|r|r|r|r|r|r|r|} @@ -220,7 +220,7 @@ die keine Parameter verwenden. Das sieht man auch entsprechend der Auswertung de mit \ac{JPQL} oder Criteria API abfragt wird. % document, documentaddresseeperson, first/last, documentcoauthorperson, count und documentfacsimile -\begin{table}[h!] +\begin{table}[H] \centering \resizebox{\textwidth}{!}{ \begin{tabular}{|r|r|r|r|r|r|r|r|r|r|r|r|r|r|r|} @@ -263,7 +263,7 @@ verbessert hat. Dies lässt auch hier den Schluss zu, dass die Erstellung der Ob benötigt. % document, documentaddresseeperson, first/last, documentcoauthorperson, count und documentfacsimile -\begin{table}[h!] +\begin{table}[H] \centering \resizebox{\textwidth}{!}{ \begin{tabular}{|r|r|r|r|r|r|r|r|r|r|r|r|r|r|r|} @@ -299,7 +299,7 @@ wurde. Dies ist dadurch zu erklären, dass im \ac{EJB} die Provider gelagert wer dem Controller bereitgestellt werden. Die Objekte selbst werden nicht im \ac{EJB}"=Cache hinterlegt. % document, documentaddresseeperson, first/last, documentcoauthorperson, count und documentfacsimile -\begin{table}[h!] +\begin{table}[H] \centering \resizebox{\textwidth}{!}{ \begin{tabular}{|r|r|r|r|r|r|r|r|r|r|r|r|r|r|r|} @@ -430,7 +430,7 @@ Wie in der Messung in \autoref{tbl:measure-criteria-api} zu sehen, unterscheiden von denen mit \ac{JPQL}. Wenn man sich den Code im Debugger betrachtet, lässt sich erkennen, dass die zusammengesetzten Abfragen in den Java-Objekten fast identisch sind. In der Datenbank sind die Anfragen identisch zu denen über JPQL. -\begin{table}[h!] +\begin{table}[H] \centering \resizebox{\textwidth}{!}{ \begin{tabular}{|r|r|r|r|r|r|r|r|r|r|r|r|r|r|r|} @@ -590,7 +590,7 @@ vorhanden Elemente, welche die Liste der Dokumente anzeigt, kopiert und auf die % document, first/last, documentaddresseeperson, documentcoauthorperson, documentfacsimile und count % document, count, first/last -\begin{table}[h!] +\begin{table}[H] \centering \resizebox{\textwidth}{!}{ \begin{tabular}{|r|r|r|r|r|r|r|r|r|r|r|r|r|r|r|} @@ -630,7 +630,7 @@ AND d.ispublishedindb = true; Nach dem 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!] +\begin{table}[H] \centering \resizebox{\textwidth}{!}{ \begin{tabular}{|r|r|r|r|r|r|r|r|r|r|r|r|r|r|r|} @@ -667,7 +667,7 @@ dieser Wert zu klein oder groß definiert ist, wird die Laufzeit verschlechtert. 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 \texttt{map}"=Funktion wird dadurch verlängert. -Das Aktivieren der Cache"=Optionen wie in \autoref{sec:performance-investigation-application:caching-openjpa} oder in %TODO schreibt in den Rand +Das Aktivieren der Cache"=Optionen wie in \autoref{sec:performance-investigation-application:caching-openjpa} oder in \autoref{sec:performance-investigation-application:cached-query} dargestellt, haben keine Auswirkung auf die Performance. Dies ist dadurch erklärbar, dass keine Objekte durch das OpenJPA"=Framework erstellt werden, sondern erst in der \texttt{map}"=Funktion des eigenen Codes und daher wird der Cache nicht genutzt. @@ -678,7 +678,7 @@ wurde die übernommene \texttt{SearchDocument}"=Klasse abermals genauer betracht Seite nochmals aufgerufen. Durch diese Umstellung fällt die Laufzeit der Datenermittlung auf circa 4 ms ab. Nun muss noch überprüft werden, welche Zeit nun der Client zum parsen der \textit{Json}"=Daten benötigt. Hierfür werden die Daten in einem versteckten \texttt{span}"=Element hinterlegt, wie es im \autoref{lst:jsf-datatable-json} zu sehen ist. -Die hinterlegte \textit{\acs{CSS}}"=Klasse ist zum Auffinden der Elemente für den späteren Javascript. Das +Die hinterlegte \textit{\ac{CSS}}"=Klasse ist zum Auffinden der Elemente für den späteren Javascript. Das \textit{ajax}"=Element im Beispiel ist notwendig, damit bei einem Seitenwechsel die gleiche Interpreter"=Funktion für die \textit{Json}"=Daten aufgerufen wird, wie beim Laden der Webseite. @@ -776,7 +776,7 @@ Die erstellte Visualisierung der Abfrage ist in \autoref{fig:explain-visualize} die Darstellung der Kosten gewählt, da ein Vergleich auf Basis der Zeit sehr schwierig ist und von äußeren Faktoren abhängt, wie zum Beispiel dem Cache. Die Kosten sind stabiler und hängen in erster Linie von der Art des Datenbestandes ab. -\begin{figure}[h!] +\begin{figure}[H] \includegraphics[width=\linewidth]{gfx/chapter05_ExplainVisualize.png} \caption{Visualisierung EXPLAIN} \label{fig:explain-visualize} @@ -828,7 +828,7 @@ an den dünneren Verbindungslinien zwischen den Knoten und der Umstellung von ei \textit{Index Scan} ersichtlich. Zeitgleich ist auch der teure \textit{HashAggregate} nicht mehr im Abfrageplan vorhanden. -\begin{figure}[h!] +\begin{figure}[H] \includegraphics[width=\linewidth]{gfx/chapter05_ExplainVisualize_with.png} \caption{Visualisierung EXPLAIN with} \label{fig:explain-visualize-with} diff --git a/chapters/thesis/chapter06.tex b/chapters/thesis/chapter06.tex index 54f817f..0a7fd12 100644 --- a/chapters/thesis/chapter06.tex +++ b/chapters/thesis/chapter06.tex @@ -9,7 +9,7 @@ der Effektivität mit beachtet. Es wurden die Konfigurationen der Caches von OpenJPA, \ac{JPA} und \ac{EJB} aktiviert und deren Auswirkung betrachtet. Bei den Caches, bei denen eine Größe angebbar ist, wurde zusätzlich mit der Anzahl variiert, um zu ermitteln, in welchem Umfang -sich diese auswirkt. Des Weiteren wird die Art der Programmierung für die Abfragen betrachtet, ob signifikante +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 \textit{Materialized View} verwendet, um zu ermitteln, ob durch einen vorverdichteten und aufbereiteten Datenbestand @@ -18,7 +18,7 @@ die Abfragen beschleunigt werden können. \section{Nutzerumfrage} \label{sec:evaluation:user-survey} -Zusätzlich war noch eine Befragung unter den Benutzer und den Entwicklern geplant. Auf Grund dessen, dass nur fünf +Zusätzlich war noch eine Befragung unter den Benutzern und den Entwicklern geplant. Auf Grund dessen, dass nur fünf Personen zur Verfügung stehen, ist dies nicht zielführend. Daher ist die einzig sinnvolle Alternative, welche gewählt wurde, ein rein technischer Ansatz. @@ -26,25 +26,24 @@ wurde, ein rein technischer Ansatz. \label{sec:evaluation:new-table} Hierfür wurde die aktuelle Datenstruktur untersucht, um zu überprüfen, ob eine Umgestaltung der Tabelle eine Verbesserung -bringen würde. Die typische Optimierung ist die Normalisierung der Tabellenstruktur. Die Tabellenstruktur ist aktuell +bringt. Die typische Optimierung ist die Normalisierung der Tabellenstruktur. Die Tabellenstruktur ist aktuell 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. Eine weitere Möglichkeit wäre es, die Duplikate auf der -Serverseite zusammenzuführen. +Dadurch würde sich die Anzahl der Dokumentenliste erhöhen. \section{Statische Webseiten} \label{sec:evaluation:static-website} -Eine Umstellung der Dokumentenliste in statische Webseite würde die Zugriffszeiten sehr verkürzen. Darüber hinaus +Eine Umstellung der Dokumentenliste in eine statische Webseite würde die Zugriffszeiten sehr verkürzen. Darüber hinaus funktionieren in statischen Webseiten aber keine Suchen oder Sortierungen. Die Sortierung könnte durch das Erstellen von statischen Seiten aller Möglichkeiten der Sortierung emuliert werden, diese würde den notwendigen Speicherbedarf der Webseite vervielfachen. Für die Suchanfragen ist dies nicht mehr möglich, da nicht alle Suchanfragen vorher definiert werden können. -Die Umstellung der Suche auf Client"=Basis wäre noch eine Möglichkeit, dafür benötigen die Clients entsprechend -Leistung und es muss eine Referenzdatei erstellt werden, die alle Informationen über die Dokumente beinhaltet, nach +Die Umstellung der Suche auf Client"=Basis wäre noch eine Möglichkeit, dafür benötigen die Clients entsprechende +Leistung und es muss eine Referenzdatei erstellt werden, welche alle Informationen über die Dokumente beinhaltet, nach welcher gesucht werden kann. Daher ist eine Umstellung auf statische Webseiten nicht sinnvoll. @@ -82,7 +81,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 beachtet werden. +den Speicherbedarf noch weiter erhöht, da diese Objekte nicht in die Zählung der Cache"=Objekte betrachtet werden. 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 @@ -91,7 +90,7 @@ zur Verfügung steht. Hierbei ist aber noch zu beachten, dass die Optimierung durch den Cache nicht die Laufzeit der Abfragen in der Datenbank enorm verringert hat, sondern die Laufzeit beim Erstellen der Objekte im \textit{OpenJPA}"=Framework. Dies sieht man -sehr gut schon bei der ersten Messung, wie in \autoref{tbl:measure-ojpa-active}. Hierbei werden die Laufzeit in der +sehr gut schon bei der ersten Messung, wie in \autoref{tbl:measure-ojpa-active}. Hierbei wird die Laufzeit in der Datenbank im Schnitt um circa 5 ms reduziert, allerdings wird die komplette Webseite fast 100 ms schneller an den Client ausgeliefert. Dies ist nur dadurch erklärbar, dass das Erstellen und mit den Datenwerte zu befüllen mehr Zeit kostet, als das Objekt aus dem Cache zu ermitteln und zurückzugeben. @@ -103,7 +102,7 @@ explizit im Cache aufgenommen und angepinnt werden. \section{Cached Queries} \label{sec:evaluation:cached-queries} -Die Optimierung über die gespeicherten Anfragen brachte keine Verbesserung hervor. Dies ist dadurch erklärbar, dass +Die Optimierung über die gespeicherten Anfragen brachte keine Verbesserung hervor. Dies ist dadurch erklärbar, dass %TODO Der Satz ist schwer zu lesen, hat sie gesagt für die diese Art nur Anfragen verwendet werden, die keinerlei Bedingungen besitzen. In diesem Fall sind in der Tabelle noch nicht freigegebene und ungültige Datensätze gespeichert, daher müssen diese vor dem Übertragen herausgefiltert werden. Aus diesem Grund werden die Anfragen in diesem Cache nicht gespeichert. @@ -113,7 +112,7 @@ Dadurch ist dieser Cache für eine Performance"=Verbesserung in dem Fall der Dok \section{Caching mit Ehcache} \label{sec:evaluation:ehcache} -Mit dem Ehcache konnte eine Verbesserung in der Performance erzielt werden. Im Vergleich zum Cache von OpenJPA sind +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 Caches, dass beim Erreichen der Grenzen alte Objekte entfernt werden müssen. @@ -145,7 +144,7 @@ Auf Grund dessen ist der \ac{EJB}"=Cache nicht für eine Performance"=Verbesseru Bei dem Vergleich zwischen den zwei Abfragemöglichkeiten der \ac{JPQL} und der Criteria API konnte in der Art der Abfragen kein Unterschied festgestellt werden. Die Abfragen der beiden Systeme sind auf Datenbankseite komplett -identisch. Auch in der Übertragung der Daten aus der Datenbank in die Java"=Objekte konnte keine Unterschied in der +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 @@ -165,7 +164,8 @@ jeweiligen Einsatzzweck besser beziehungsweise einfacher zu programmieren ist. D 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 ausgegangen werden kann. Gerade bei einer größeren Anzahl lohnt es sich den Hint auf \textit{parallel} zu setzen. -Gleiches gilt dem Hint SubclassFetchMode, dieser steuert dimensionierte Abfragen im Falle von abgeleiteten Klassen. +Gleiches gilt bei dem Hint \texttt{SubclassFetchMode}, dieser steuert dimensionierte Abfragen im Falle von +abgeleiteten Klassen. \section{Materialized View} \label{sec:evaluation:materialized-view} @@ -233,7 +233,7 @@ ermittelt, dieser mit der Haupttabelle verknüpft und nun die anderen Tabellen d 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ürs Paging verwendet werden und die Abfrage aus +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 diff --git a/chapters/thesis/chapter07.tex b/chapters/thesis/chapter07.tex index ec0867b..e24e372 100644 --- a/chapters/thesis/chapter07.tex +++ b/chapters/thesis/chapter07.tex @@ -17,9 +17,9 @@ Durch die Ausgangsmessungen war erkennbar, dass der größte Teil der Verarbeitu liegt. Die Messung der Abfragen auf der Datenbank wiederum konnte die hohe Verarbeitungszeit nicht bestätigen, daher lag hier die Vermutung nahe, dass der Großteil der Zeit im \ac{ORM} verloren geht. -Die Methode der Nutzerumfrage wurde nicht weiterverfolgt, da diese auf Grund zu wenigen Bedienern nicht zielführend war. +Die Methode der Nutzerumfrage wurde nicht weiterverfolgt, da diese auf Grund von zu wenigen Bedienern nicht zielführend war. Bei der Untersuchung der Datenbank wurde festgestellt, dass die Struktur aktuell für die Anwendung optimal ist und -daher eine Restrukturierung keine Vorteile entstehen lässt. Die statische Webseite und die komplett Client basierte +daher eine Restrukturierung keine Vorteile entstehen lässt. Die statische Webseite und die komplett client basierte 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 @@ -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 ein gute Optimierung +Mit der Übernahme der \textit{Materialized View} aus dem Wedekind"=Projekt konnte erstmalig 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. @@ -60,7 +60,7 @@ für die weiteren Verlinkungen enorm reduziert wurde. Somit konnte der Datenbank zugreifen und damit die Abfragen zusätzlich beschleunigen. Die Untersuchungen zeigen, dass mehrere Möglichkeiten zur Optimierung existierten, um die Zugriffe auf die -Briefeditionen zu beschleunigen und das das größte Optimierungspotential in dem \ac{ORM} liegt. Welche der +Briefeditionen zu beschleunigen und dass das größte Optimierungspotential in dem \ac{ORM} liegt. Welche der %dass oder das Optimierungen verwendet werden, liegt an der Komplexität der Abfrage und der bereitgestellten Ressourcen des Servers. diff --git a/marco-galster-config.tex b/marco-galster-config.tex index 5b84c9d..496ac3d 100644 --- a/marco-galster-config.tex +++ b/marco-galster-config.tex @@ -66,3 +66,5 @@ \usepackage{soul} % ToDos erstellen mit \todo{...} \usepackage{todonotes} +% für bessere Positionierung von Graphiken mit dem Kürzel H +\usepackage{float} diff --git a/thesis.pdf b/thesis.pdf index f096a6e..075e2c5 100644 Binary files a/thesis.pdf and b/thesis.pdf differ diff --git a/thesis.tex b/thesis.tex index c12c38a..df7c185 100644 --- a/thesis.tex +++ b/thesis.tex @@ -17,6 +17,14 @@ %\renewcommand{\myTime}{22. Juli 2024\xspace} \renewcommand{\myVersion}{version 1.0\xspace} +\makeatletter +\addto\extrasngerman{ + % Definition, um Umbrüche innerhalb von Text und Nr zu erlauben, damit kein + % überschreiben des Randes auftritt + \def\sectionautorefname{Abschnitt\hskip\z@skip} +} +\makeatother + % https://en.wikibooks.org/wiki/LaTeX/Source_Code_Listings %\lstinputlisting[frame=tb,language=SQL,caption={ein sql beispiel},label=lst:tester]{chapters/thesis/chapter05_example.sql} \newcommand{\includecode}[4][c]{\lstinputlisting[caption=#4,label=#3,language=#1]{#2}} @@ -164,9 +172,9 @@ % 2. Bei Before Lunch "Build artifact" hinzufügen und "WedekindJSF.war" auswählen % 3. Unter Deployment "Artifact" "WedekindJSF.war" hinzufügen % 4. Sollte es Probleme mit dem Deployment geben, ala "kann ...Servlet-class nof found" einfach alle target-Verzeichnis löschen -% und erneut deployen oder vielleicht ein Rebuild auf dem Projekt probieren +% und erneut Deployen oder vielleicht ein Rebuild auf dem Projekt probieren -% Konfiguration Glassfish/Payara (Muss scheinbar nach jedem neustart des Rechners gemacht werden) +% Konfiguration GlassFish/Payara (Muss scheinbar nach jedem neustart des Rechners gemacht werden) % 1. Payara-Server starten, damit man an die Admin-Oberfläche kommt unter http://localhost:4848/ % > /opt/payara/bin/asadmin start-domain domain1 % 2. Unter Ressources\JDBC\JDBC Connection Pools einen neuen Anlegen: