mdn/bachelor-thesis
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Daily CheckIn

Browse source
This commit is contained in:
marcodn 2024-09-10 00:46:35 +02:00
parent c54f8d64b8
commit fe6592bfa2
10 changed files with 102 additions and 49 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

11
chapters/expose/chapter01.tex
View file

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

2
chapters/thesis/appendix01.tex
View file

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

4
chapters/thesis/appendix02_timing.sh
View file

@ -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/listsearch.xhtml"
"$hostname/view/document/list.xhtml"
#"$hostname/view/document/listsearch.xhtml"
)
#print_process

17
chapters/thesis/chapter01.tex
View file

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

19
chapters/thesis/chapter02.tex
View file

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

8
chapters/thesis/chapter03.tex
View file

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

4
chapters/thesis/chapter04.tex
View file

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

84
chapters/thesis/chapter05.tex
View file

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

BIN
expose.pdf
View file

Binary file not shown.

BIN
thesis.pdf
View file

Binary file not shown.