Daily CheckIn
This commit is contained in:
marcodn
parent
a795b3a43c
commit
e60246828e
10 changed files with 94 additions and 79 deletions
|
|
@ -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" #Materialized View
|
||||
)
|
||||
|
||||
#print_process
|
||||
|
|
@ -108,5 +108,5 @@ echo ""
|
|||
main 10 ${url_arr[@]}
|
||||
|
||||
echo ""
|
||||
##print_process
|
||||
#print_process
|
||||
print_docker_process
|
||||
|
|
|
|||
|
|
@ -16,11 +16,11 @@ gestartet und initialisiert sind. Wenn dies nicht der Fall ist, laufen die Abfra
|
|||
wie dargestellt, über die Statistik von Docker zu ermitteln. Darüber wird überwacht, dass die CPU-Auslastung auf ein
|
||||
niedriges Level fällt, danach kann das Skript für die Messungen aufgerufen werden.
|
||||
|
||||
\includecode[bash]{chapters/thesis/appendix04_calling_script.sh}{lst:calling_script}{Calling Script}
|
||||
|
||||
\begin{lstlisting}[language=Bash,caption={Aufrufe des Unterstützungsscriptes},label=lst:calling_script_exec]
|
||||
callscript.sh measinit
|
||||
callscript.sh -rppf=_testname measres
|
||||
callscript.sh dcstats
|
||||
callscript.sh -rppf=_testname measrun
|
||||
\end{lstlisting}
|
||||
\end{lstlisting}
|
||||
|
||||
\includecode[bash]{chapters/thesis/appendix04_calling_script.sh}{lst:calling_script}{Unterstützungsscript}
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@
|
|||
Für die Protokollierung der Abläufe im \ac{JSF} werden zwei Klassen benötigt. Über die Factory \ref{lst:logger_factory},
|
||||
wird die Wrapper"=Klasse in die Bearbeitungsschicht eingeschleust. Diese Wrapper"=Klasse \ref{lst:logger} beinhaltet
|
||||
dann die eigentliche Performance"=Messung, inklusive der Ausgabe in die Log"=Datei des \textit{GlassFish}"=Servers.
|
||||
Zusätzlich muss in der Konfiguration \texttt{faces-config.xml} noch angepasst werden, wie in
|
||||
Zusätzlich muss die Konfiguration \texttt{faces-config.xml} noch angepasst werden, wie in
|
||||
\ref{lst:logger_factory_activate}, um die Factory durch das System aufrufen zu lassen.
|
||||
|
||||
\includecode[java]{chapters/thesis/appendix06_Logger.java}{lst:logger}{Vdi Logger}
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ Wenn der Speicher zu gering wird, werden die Zwischenergebnisse in temporäre Da
|
|||
berechnet sich aus \texttt{shared""\_buffers} dividiert durch \texttt{max\_connections} \citep{ConfigTo12:online}.
|
||||
Sollte die Berechnung außerhalb der Grenzwerte von 1 MB und 256 MB liegen, ist der jeweilige Grenzwert zu verwenden.
|
||||
Um zu ermitteln, ob die Konfiguration richtig ist, muss im PostgreSQL die Einstellung \texttt{log\_""temp\_""files} auf 0
|
||||
gesetzt werden. Mit dieser kann ermittelt, ob temporäre Dateien verwendet werden sowie deren Größe. Bei vielen kleineren
|
||||
gesetzt werden. Mit dieser wird ermittelt, ob temporäre Dateien verwendet werden sowie deren Größe. Bei vielen kleineren
|
||||
Dateien sollte der Grenzwert erhöht werden. Bei wenigen großen Dateien ist es ist sinnvoll den Wert so zu belassen.
|
||||
|
||||
Für die Wartungsaufgaben wie VACUUM oder dem Erstellen von Indexen wird die Begrenzung über die Einstellung
|
||||
|
|
@ -36,7 +36,7 @@ als \texttt{work\_mem} sein.
|
|||
|
||||
Nachfolgend wird mit dem Systemtools, wie den Konsolenanwendungen \textit{htop} und \textit{free}, die Auslastung des Servers
|
||||
überprüft. Hierbei ist die CPU"=Leistung, der aktuell genutzte Arbeitsspeicher, sowie die Zugriffe auf die Festplatte
|
||||
die wichtigen Faktoren zur Bewertung.
|
||||
die wichtigen Faktoren zur Bewertung. %TODO wichtigsten?
|
||||
|
||||
Die CPU"=Leistung sollte im Schnitt 70\% nicht überschreiten, für kurze Spitzen wäre dies zulässig, um die gestellten
|
||||
Anfragen schnell genug abarbeiten zu können. Daher soll verhindert werden, dass der Server an seiner Leistungsgrenze
|
||||
|
|
@ -67,7 +67,7 @@ immer in einer chronologisch aufsteigenden Form darzustellen.
|
|||
|
||||
Aktuell verwenden die Editoren die Dokumentenliste, um die Briefe eines Adressaten zu filtern und diese in
|
||||
chronologische Reihenfolge aufzulisten und zu untersuchen, wie die Kommunikation zwischen Herrn Wedekind und dem Adressaten
|
||||
abgelaufen ist. Ebenso wird nach Standorten sortiert, um zu ermitteln, welche Personen sich im Zeitraum am gleichen
|
||||
abgelaufen ist. Ebenso wird nach Standorten sortiert, um zu ermitteln, welche Personen sich in einem Zeitraum am gleichen
|
||||
Ort aufgehalten haben.
|
||||
|
||||
Da die Daten in der 3. Normalform in der Datenbank gespeichert werden, sind einige Relationen für die Abfragen
|
||||
|
|
@ -79,12 +79,12 @@ weitere Relationen notwendig sind.
|
|||
\includecode[SQL]{chapters/thesis/chapter03_documentlist_sub.sql}{lst:documentlist_sub}{Sub-Abfrage pro Dokument}
|
||||
|
||||
Nach aktuellem Stand beinhaltet die Datenbank circa 5400 Briefe, für die jeweils zwei bis sieben eingescannte Faksimile
|
||||
gespeichert werden. Diese Graphik-Dateien werden im TIFF-Format abgespeichert und benötigen zwischen 1 und 80 MB
|
||||
gespeichert werden. Diese Graphik"=Dateien werden im TIFF"=Format abgespeichert und benötigen zwischen 1 und 80 MB
|
||||
Speicherplatz. Dadurch kommt die Datenbank aktuell auf circa 3,8 GB.
|
||||
|
||||
Wie in \autoref{ch:basics} dargestellt, besteht die eigentliche Anwendung aus mehreren Schichten. Die
|
||||
PostgreSQL"=Schicht wurde schon im vorherigen Kapitel betrachtet. Daher werden nun die weiteren Schichten des
|
||||
GlassFish"=Server in aufsteigender Reihenfolge betrachtet.
|
||||
GlassFish"=Servers in aufsteigender Reihenfolge betrachtet.
|
||||
|
||||
Die OpenJPA Cache Schicht wird nun einzeln untersucht. Hierfür werden zuerst die Cache"=Statistik für Object"=Cache
|
||||
und Query"=Cache aktiviert \citep[315]{MüllerWehr2012}. Die somit erfassten Werte werden über eine Webseite
|
||||
|
|
@ -122,16 +122,16 @@ Die Abfragen werden ebenfalls untersucht und mit verschiedenen Methoden optimier
|
|||
SQL"=Anfragen umgestellt und die Ausführungszeiten überprüft. Zum anderen werden die Abfragen durch Criteria API erzeugt
|
||||
und dessen Ausführungszeit ermittelt.
|
||||
|
||||
Zusätzlich werden im SQL-Server Optimierungen vorgenommen, darunter zählen die \textit{Materialized View}, welche eine
|
||||
erweiterte Sicht ist. Neben der Abfrage der Daten beinhalteten diese auch vorberechneten Daten der Abfrage, womit
|
||||
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 der Abfragedauern verkürzen können.
|
||||
der Performance und damit eine Reduzierung der Abfragedauern erreichen.
|
||||
|
||||
Damit die Messungen nachvollziehbar bleiben, werden die Testaufrufe durch ein Bash-Script automatisiert gerufen.
|
||||
Damit die Messungen nachvollziehbar bleiben, werden die Testaufrufe durch ein Bash"=Script automatisiert gerufen.
|
||||
Wichtig hierbei ist, dass die Webseite immer vollständig gerendert vom Server an den Client übertragen wird.
|
||||
Somit kann die clientseitige Performance ignoriert werden, da alle Daten bereits direkt in diesem einem Aufruf bereitgestellt
|
||||
werden. In dem Skript werden zum einen die Laufzeiten der Webanfragen ermittelt, zum anderen die kürzeste, die längste und die
|
||||
durchschnittliche Laufzeit ermittelt. Auf Grund der Speicherprobleme werden auch die Speicherbenutzung des
|
||||
durchschnittliche Laufzeit ermittelt. Auf Grund der Speicherprobleme wird auch die Speicherbenutzung des
|
||||
\textit{GlassFish}"=Servers vor und nach den Aufrufen ermittelt. Zum Schluss werden noch die Log"=Dateien des
|
||||
\textit{PostgreSQL}"=Servers über das Tool \textit{pgBadger} analysiert und als Bericht aufbereitet.
|
||||
|
||||
|
|
|
|||
|
|
@ -77,7 +77,7 @@ log_rotation_size = 100MB
|
|||
|
||||
Über die Konfiguration unter \autoref{lst:postgresql_logconf} wird definiert welche Werte protokolliert werden. Die
|
||||
wichtigste Einstellung ist \texttt{log\_min\_duration\_statement}, diese definiert, ab welcher Laufzeit eine Abfrage
|
||||
protokolliert werden soll. Mit dem Wert 0 werden alle Abfragen protokolliert. Alle weitere Einstellungen sind so
|
||||
protokolliert werden soll. Mit dem Wert 0 werden alle Abfragen protokolliert. Alle weiteren Einstellungen sind so
|
||||
gesetzt, dass nicht unnötige Abfragen für die spätere Auswertung mit \textit{pgBadger} protokolliert werden.
|
||||
Zusätzlich ist die Einstellung \texttt{log\_temp\_files} auf 0 zu setzen, dadurch werden alle erzeugten temporären
|
||||
Dateien und ihre Größe ebenfalls protokolliert. Diese Dateien entstehen, wenn der temporäre Puffer für die Abfrage
|
||||
|
|
@ -114,7 +114,7 @@ geschätzte Breite jeder Zeile (\textit{width}). Der Wert von \textit{costs} wir
|
|||
Bei der Option \texttt{ANALYZE} wird die Abfrage ausgeführt und die echten Werte und Laufzeiten angezeigt. Ohne diese
|
||||
wird nur der Plan erstellt und dargestellt. Durch \texttt{VERBOSE} wird der Abfrageplan um zusätzliche Informationen
|
||||
angereichert. Die Option \texttt{BUFFERS} erweitert die Informationen über die Nutzung der Caches. Für eine
|
||||
Zusammenfassung am Ende des Abfrageplans, gibt es die Option \texttt{summary}. Eine vereinfachte Form des Aufrufs
|
||||
Zusammenfassung am Ende des Abfrageplans, gibt es die Option \texttt{SUMMARY}. Eine vereinfachte Form des Aufrufs
|
||||
ist in \autoref{lst:explain-easy} dargestellt.
|
||||
|
||||
\begin{lstlisting}[language=SQL,caption={Aufruf von EXPLAIN},label=lst:explain-easy]
|
||||
|
|
@ -144,13 +144,13 @@ Daher muss abgewägt werden, ob die Performance-Verbesserung trotz der zusätzli
|
|||
als sinnvoll erachtet werden kann.
|
||||
|
||||
Zusätzlich kann über die Systemtabelle \texttt{pg\_statistic} oder die lesbarere Systemsicht \texttt{pg\_stats} die
|
||||
aktuelle statistischen Informationen über eine Tabelle und deren Spalten ermittelt werden. In dieser Tabelle werden
|
||||
aktuellen statistischen Informationen über eine Tabelle und deren Spalten ermittelt werden. In dieser Tabelle werden
|
||||
durch das \texttt{ANALYZE} beziehungsweise \texttt{VACUUM ANALYZE} Kommando die Informationen zum Anteil der
|
||||
\texttt{NULL}"=Werte (null\_frac), durchschnittlichen Größe (avg\_width), unterschiedlicher Werte (n\_distinct) und
|
||||
weitere gesammelt und für die Erstellung der Abfragepläne verwendet \citep{PostgreS39:online}. Diese Information
|
||||
sollte vor dem erstellen eines Index betrachtet werden.
|
||||
|
||||
Diese Informationen können noch durch das Kommando \linebreak\texttt{CREATE STATISTICS} erweitert werden, für einen besseren
|
||||
Abfrageplan. Das Aktivieren der zusätzlichen Statistiken sollte immer in Verbindung mit der Überprüfung des
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -15,9 +15,9 @@ Konfiguration mehrfach aufgerufen. Hierbei hat sich gezeigt, dass der erste Aufr
|
|||
gedauert hat. Die weiteren Aufrufe benötigen im Durchschnitt noch 600 ms. Beim achten Aufruf des Scripts hat der
|
||||
Server nicht mehr reagiert und im Log ist ein \textit{OutOfMemoryError} protokolliert worden.
|
||||
|
||||
Nach einem Neustart des Servers konnte das gleiche Verhalten wieder reproduziert werden. Daraufhin wurde das Test"=Script
|
||||
um die Anzeige der aktuellen Speicherverwendung des Payara"=Servers erweitert, um diese zeitgleich zu beobachten. Diese
|
||||
Auswertung zeigte, dass der Server mit circa 1500 MB RSS Nutzung an seine Grenzen stößt. Diese Grenze wurde durch die
|
||||
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
|
||||
Konfigurationsänderung im Payara-Server von \texttt{-Xmx512m} auf \texttt{-Xmx4096m} nach oben verschoben. Nun werden
|
||||
circa 60 Aufrufe des Scripts benötigt, damit der Server nicht mehr reagiert. Hierbei wird aber kein \textit{OutOfMemoryError}
|
||||
in der Log-Datei protokolliert und der Server verwendet nun circa 4700 MB RSS. Bei allen Tests war noch mehr als die
|
||||
|
|
@ -32,7 +32,7 @@ Aufrufe steuert. Die Ergebnisse werden in eine Tabelle überführt, wie in \auto
|
|||
Hierbei werden die Aufrufzeiten der Webseite aus dem Skript für die Zeitmessung mit Mindest"~, Durchschnitt"~ und
|
||||
Maximalzeit aufgenommen, hierbei ist eine kürzere Zeit besser. Zusätzlich wird die Anzahl der aufgerufenen \ac{SQL} Abfragen
|
||||
ermittelt, auch hier gilt, je weniger Aufrufe desto besser. Als letztes wird noch der verwendete Arbeitsspeicher
|
||||
vom \textit{GlassFish}"=Server vor und nach dem Aufruf ermittelt und die Differenz gebildet, hierbei sollte im idealen
|
||||
vom \textit{Payara}"=Server vor und nach dem Aufruf ermittelt und die Differenz gebildet, hierbei sollte im idealen
|
||||
Fall die Differenz bei 0 liegen. Dieser Aufbau gilt für alle weiteren Messungen. Zusätzlich werden noch die Laufzeiten
|
||||
der \ac{JSF} ermittelt und die durchschnittlichen Zeiten mit in der Tabelle dargestellt, und auch hier ist es besser,
|
||||
wenn die Zeiten kürzer sind.
|
||||
|
|
@ -63,14 +63,14 @@ gehalten werden sollten.
|
|||
\end{table}
|
||||
|
||||
Vor jedem weiteren Test"=Lauf wird die Domain beendet und komplett neugestartet, um mit einer frischen Instanz zu
|
||||
beginnen. Hierbei ist aufgefallen, dass fast immer 62 Abfragen zur Startup-Phase dazugehört haben, unabhängig von den
|
||||
beginnen. Hierbei ist aufgefallen, dass fast immer 62 Abfragen zur Startup-Phase dazugehören, unabhängig von den
|
||||
konfigurierten Cache Einstellungen. Einige dieser Abfragen sind durch das Erstellen der \textit{Materialized View}
|
||||
\textit{searchreference} und \textit{searchfulltext} erklärbar. Zusätzlich ist noch ein zyklischer Dienst
|
||||
\textit{SearchEntityService} vorhanden, der zum Start und alle sechs Stunden den Datenbestand für die Suche aufbereitet
|
||||
und entsprechend einige Abfragen an die Datenbank absetzt. Da weder die Sichten noch der Dienst für die Dokumentenliste
|
||||
benötigt werden, wurde der Dienst und das Erstellen im Code für die weiteren Tests deaktiviert.
|
||||
benötigt werden, ist der Dienst und das Erstellen im Code für die weiteren Tests deaktiviert.
|
||||
|
||||
Da die Abfragezeiten auf der Datenbank zu gering waren, um eine Verbesserung feststellen zu können, wurde für den
|
||||
Da die Abfragezeiten auf der Datenbank zu gering sind, um eine Verbesserung feststellen zu können, wird für den
|
||||
PostgreSQL und den Payara"=Server ein Docker"=Container erzeugt und diese limitiert. Die Konfiguration ist in
|
||||
\autoref{ap:docker_config} beschrieben.
|
||||
|
||||
|
|
@ -79,13 +79,13 @@ Speicher der Anwendung beobachtet, sondern die Speichernutzung des Docker-Contai
|
|||
ist es besser, wenn es keine oder nur geringe Änderungen vor und nach dem Aufruf der Webseite gibt, ein steigender Wert
|
||||
zeigt an, dass der verwendete Speicher nicht sauber freigegeben werden kann.
|
||||
|
||||
Für die Ausführungszeiten der \ac{SQL}"=Abfragen wurden nur die sechs Abfragen für die Darstellung der Tabelle beachtet.
|
||||
Hierzu zählt die Hauptabfrage der Dokumenten"=-Tabelle, die Ermittlung des letzten und ersten Eintrags in der Tabelle,
|
||||
Für die Ausführungszeiten der \ac{SQL}"=Abfragen werden nur die sechs Abfragen für die Darstellung der Tabelle beachtet.
|
||||
Hierzu zählt die Hauptabfrage der Dokumenten"=Tabelle, die Ermittlung des letzten und ersten Eintrags in der Tabelle,
|
||||
die Ermittlung der Adressen des Autors, die Ermittlung der Koautoren, die Ermittlung der Faksimile, sowie die Ermittlung
|
||||
der Anzahl aller vorhandenen Dokumente.
|
||||
|
||||
Zusätzlich wird die Zeit des Rendern der Sicht gemessen. Die erste Messung erfasst die komplette Laufzeit die fürs Rendern
|
||||
notwendig benötigt wird. Diese Zeit wird unterteilt in die Messungen für das Laden der Daten aus der Datenbank und das Erstellen
|
||||
notwendig ist. Die zweite Messung ermittelt die Zeit für das Laden der Daten aus der Datenbank und das Erstellen
|
||||
der Java"=Objekte inklusive dem Befüllen mit den geladenen Daten.
|
||||
|
||||
\begin{table}[H]
|
||||
|
|
@ -157,7 +157,7 @@ Bei einer erhöhten Cache"=Größe, von 1000 auf 10000, zeigt sich auf den erste
|
|||
\autoref{tbl:measure-ojpa-active-bigger} ersichtlich ist. Der erste Aufruf entspricht der Laufzeit mit geringerer
|
||||
Cache"=Größe, aber schon die Anfragen an die Datenbank gehen drastisch zurück. Bei den weiteren Aufrufen werden im
|
||||
Schnitt nun nur noch 6 Anfragen pro Seitenaufruf an die Datenbank gestellt, wodurch die Laufzeit im Schnitt nochmal
|
||||
um 100 ms beschleunigt werden konnte.
|
||||
um 100 ms beschleunigt werden kann.
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
|
|
@ -254,7 +254,7 @@ aktiviert und muss explizit deaktiviert werden, wenn dies nicht gewünscht ist.
|
|||
Cache"=Manager aktiviert werden, dieser kann entweder durch Code programmiert werden oder über eine Konfiguration
|
||||
in der \textit{ehcache.xml}.
|
||||
|
||||
Anhand der Auswertung von \ref{tbl:measure-ehcache-active} sieht man, dass der Ehcache einen starke Performance
|
||||
Anhand der Auswertung von \autoref{tbl:measure-ehcache-active} sieht man, dass der Ehcache eine starke Performance
|
||||
Verbesserung aufbringt. Über die Performance"=Statistik"=Webseite kann beobachtet werden, dass bei gleichen Aufrufen
|
||||
der Webseite nur die Treffer in Cache steigen, aber die Misses nicht. Ebenfalls erhöht sich die Anzahl der Objekte
|
||||
im Cache nicht. Zusätzlich steigt in diesem Fall der Speicherverbrauch nur gering bis gar nicht. Des Weiteren zeigt sich,
|
||||
|
|
@ -289,14 +289,14 @@ benötigt.
|
|||
\label{sec:performance-investigation-application:caching-ejb}
|
||||
|
||||
Die Cache"=Einstellungen des \ac{EJB} sind in der Admin-Oberfläche des Payara-Servers zu erreichen. Unter dem Punkt
|
||||
Configurations $\Rightarrow$ server"=config $\Rightarrow$ \ac{EJB} Container werden zum einen die minimalen und maximalen
|
||||
Größen des Pools definiert werden. 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 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
|
||||
Erweiterung definiert.
|
||||
|
||||
Anhand der Auswertung der \autoref{tbl:measure-ejb-cache-active} ist ersichtlich, dass der \ac{EJB}"=Cache keine
|
||||
Auswirkung auf die Performance hat. Ebenso ist es ersichtlich, dass die Anzahl der Datenbankabfragen nicht reduziert
|
||||
wurde. Dies ist dadurch zu erklären, dass im \ac{EJB} die Provider gelagert werden, die über Dependency Injection
|
||||
dem Controller bereitgestellt werden. Die Objekte selbst werden nicht im \ac{EJB}"=Cache hinterlegt.
|
||||
werden. Dies ist dadurch zu erklären, dass im \ac{EJB} die Provider gelagert sind, die über Dependency Injection
|
||||
dem Controller bereitgestellt werden. Die Objekte selbst sind nicht im \ac{EJB}"=Cache hinterlegt.
|
||||
|
||||
% document, documentaddresseeperson, first/last, documentcoauthorperson, count und documentfacsimile
|
||||
\begin{table}[H]
|
||||
|
|
@ -323,9 +323,11 @@ dem Controller bereitgestellt werden. Die Objekte selbst werden nicht im \ac{EJB
|
|||
\section{Abfragen JPQL}
|
||||
\label{sec:performance-investigation-application:query-jpql}
|
||||
|
||||
Für die \ac{JPQL} wird ein \ac{SQL} ähnlicher Syntax verwendet, um die Abfragen an die Datenbank durchzuführen. Für die
|
||||
Dokumentenliste wird der Code aus \autoref{lst:jpql-document-list-jpql} verwendet. Die Namen mit vorangestellten
|
||||
Doppelpunkt sind Übergabevariablen.
|
||||
Für die \ac{JPQL} wird ein \ac{SQL} ähnlicher Syntax verwendet, um die Abfragen an die Datenbank durchzuführen. Der
|
||||
nachfolgende Code für die Dokumentenliste, welche in \ac{JPQL} geschrieben ist, ist aus dem DFG"=Projekt
|
||||
\citep{DFGProje43:online} entnommen. Das \autoref{lst:jpql-document-list-jpql} zeigt den \ac{JPQL}"=Code welcher unter
|
||||
dem Namen \textit{Document.""findAll} hinterlegt ist, um die Daten aus dem \textit{PostgreSQL}"=Server zu ermitteln.
|
||||
Die enthaltenen Namen mit vorangestellten Doppelpunkt sind Übergabevariablen, um die Auswahl einzuschränken.
|
||||
|
||||
\begin{lstlisting}[language=Java,caption={JPQL Dokumentenliste},label=lst:jpql-document-list-jpql]
|
||||
SELECT DISTINCT d FROM Document d
|
||||
|
|
@ -337,9 +339,9 @@ AND d.isPublishedInDb = :published
|
|||
ORDER BY d.documentId ASC
|
||||
\end{lstlisting}
|
||||
|
||||
In dem dazugehörigen Code am Server wird der JPQL-Code als NamedQuery hinterlegt und über den Name
|
||||
\textit{Document.""findAll} referenziert. Eine Veränderung der Abfrage ist hier leider nicht möglich, wie man im Code
|
||||
aus \autoref{lst:jpql-document-list} sehen kann.
|
||||
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
|
||||
der Paginierung und die Hints hinterlegt.
|
||||
|
||||
\begin{lstlisting}[language=Java,caption={Java JPQL Dokumentenliste},label=lst:jpql-document-list]
|
||||
List<Document> myResultList = createNamedTypedQuery("Document.findAll")
|
||||
|
|
@ -356,7 +358,7 @@ if(myResultList != null && !myResultList.isEmpty()) {
|
|||
}
|
||||
\end{lstlisting}
|
||||
|
||||
Da dieser Code direkt so aus dem Projekt kommt, wird hierfür keine gesonderte Zeitmessung durchgeführt, da diese der
|
||||
Da dieser Code direkt so aus dem Projekt stammt, wird hierfür keine gesonderte Zeitmessung durchgeführt, da diese der
|
||||
Messung aus \autoref{tbl:measure-without-cache} entspricht.
|
||||
|
||||
Für die Optimierung wurden noch zusätzlich die Hints \texttt{openjpa.""hint.""OptimizeResultCount},
|
||||
|
|
@ -390,12 +392,13 @@ wurde fast geviertelt. Dies zeigt, dass die einzelnen Aufrufe je Dokument aufwen
|
|||
der abhängigen Daten und das zusammensetzen in der OpenJPA-Schicht.
|
||||
|
||||
Der letzte Hint \texttt{openjpa.""FetchPlan.""MaxFetchDepth} schränkt die rekursive Tiefe ein, für die abhängige
|
||||
Objekte mitgeladen werden. Lediglich auf Grund fehlender Datenbestände wird die Abfrage beschleunigt.
|
||||
Objekte mitgeladen werden. Lediglich auf Grund fehlender Datenbestände wird die Abfrage beschleunigt und ist daher
|
||||
in diesem Fall nicht zu verwenden.
|
||||
|
||||
\section{Abfragen Criteria API}
|
||||
\label{sec:performance-investigation-application:query-criteria-api}
|
||||
|
||||
Für die Criteria API wird die Abfrage nicht in einem \ac{SQL}"=Dialekt beschreiben, hierbei werden über Attribute die
|
||||
Für die Criteria API wird die Abfrage nicht in einem \ac{SQL}"=Dialekt beschrieben, hierbei werden über Attribute die
|
||||
Verlinkung zur Datenbank durchgeführt. An der Klasse selbst wird der Tabellenname definiert und an den Attributen die
|
||||
Spaltennamen. Um die Anfrage durchzuführen, muss nun nur noch die Datenklasse angegeben und mit den Parametern
|
||||
versorgt werden, wie es in \autoref{lst:criteria-api} gezeigt wird.
|
||||
|
|
@ -451,7 +454,7 @@ Abfragen in den Java-Objekten fast identisch sind. In der Datenbank sind die Anf
|
|||
\label{tbl:measure-criteria-api}
|
||||
\end{table}
|
||||
|
||||
Daher bringt die Criteria API keinen performance Vorteil gegenüber der JPQL"=Implementierung. Somit können beide
|
||||
Daher bringt die Criteria API keinen Performance Vorteil gegenüber der JPQL"=Implementierung. Somit können beide
|
||||
Implementierungen ohne Bedenken gegeneinander ausgetauscht werden, und die verwendet werden, die für den Anwendungsfall
|
||||
einfacher umzusetzen ist.
|
||||
|
||||
|
|
@ -614,10 +617,10 @@ vorhanden Elemente, welche die Liste der Dokumente anzeigt, kopiert und auf die
|
|||
Wie in \autoref{tbl:measure-materialized-view} zu sehen ist, bringt die Verwendung der \textit{Materialized View} eine
|
||||
Verbesserung in verschiedenen Punkten. Zum einen ist eine Verbesserung der Aufrufzeiten zu erkennen, zum anderen fällt
|
||||
der Speicheranstieg weniger stark aus. Die Verbesserung der Aufrufzeiten lässt sich zusätzlich erklären, dass hier nun
|
||||
nur noch vier statt der sechs an die Datenbank gestellt werden, da die Einzelabfragen für die Adressen der
|
||||
nur noch vier statt der sechs Abfragen an die Datenbank gestellt werden, da die Einzelabfragen für die Adressen der
|
||||
Personen und der Koautoren komplett entfallen.
|
||||
|
||||
Nach einer weiteren Untersuchung des Quellcodes wird festgestellt, dass bei jeder Anfrage die gleiche Bedingungen
|
||||
Nach einer weiteren Untersuchung des Quellcodes wird festgestellt, dass bei jeder Anfrage die gleichen Bedingungen
|
||||
benötigt werden. Da die Sicht nun explizit für diese Anfrage geschaffen ist, werden die Bedingungen nun direkt in die
|
||||
Sicht mit integriert. Dies bedeutet eine Erweiterung der Sicht aus \autoref{lst:sql-materialized-view} um
|
||||
\autoref{lst:sql-materialized-view-ext} und das Entfernen der Parameter aus dem \ac{SQL}"=Anfragen im Java"=Code.
|
||||
|
|
@ -627,7 +630,7 @@ WHERE d.validuntil > NOW()
|
|||
AND d.ispublishedindb = true;
|
||||
\end{lstlisting}
|
||||
|
||||
Nach dem Anpassungen haben sich dann die Werte aus \autoref{tbl:measure-materialized-view-ext} ergeben. Diese Werte
|
||||
Nach den Anpassungen haben sich dann die Werte aus \autoref{tbl:measure-materialized-view-ext} ergeben. Diese Werte
|
||||
zeigen nur minimale Unterschiede in den Zeiten, diese sind auf Messtoleranzen zurückzuführen.
|
||||
|
||||
\begin{table}[H]
|
||||
|
|
@ -795,10 +798,10 @@ sehr einfach verifiziert werden. Damit wird die Verwendung von \textit{Seq Scan}
|
|||
von \textit{Index Scan}.
|
||||
|
||||
Die beste Optimierung hierbei ist, die Menge der Datensätze so früh wie möglich einzuschränken. Da die Verwendung von
|
||||
\texttt{order by} innerhalb eines Sub"=Selects nicht erlaubt ist, verwenden wir hierfür eine \textit{Common Table
|
||||
Expression}, wie es in \autoref{lst:explain-optimize-cte} zu sehen ist. Zusätzlich wurde noch ein Index auf der
|
||||
\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
|
||||
\autoref{lst:explain-optimize-cte-idx} zur sehen, damit in der \textit{Common Table Expression} nur der Index verwendet
|
||||
\autoref{lst:explain-optimize-cte-idx} zu sehen, damit in der \textit{Common Table Expression} nur der Index verwendet
|
||||
werden kann und kein zusätzlicher Zugriff in die Tabelle notwendig ist.
|
||||
|
||||
\begin{lstlisting}[language=SQL,caption={Optimierung mit Common Table Expression},label=lst:explain-optimize-cte]
|
||||
|
|
@ -822,7 +825,7 @@ create index idx_document_with_stmt on document using btree
|
|||
, startday desc, id );
|
||||
\end{lstlisting}
|
||||
|
||||
Mit diesen Umstellungen erkennt man, dass die Kosten entsprechend gefallen sind. Ebenfalls konnten die Laufzeit um
|
||||
Mit diesen Umstellungen erkennt man, dass die Kosten entsprechend gefallen sind. Ebenfalls konnte die Laufzeit um
|
||||
mehr als den Faktor drei reduziert werden. Die Optimierung ist in \autoref{fig:explain-visualize-with} sehr deutlich
|
||||
an den dünneren Verbindungslinien zwischen den Knoten und der Umstellung von einigen \textit{Seq Scan} zu
|
||||
\textit{Index Scan} ersichtlich. Zeitgleich ist auch der teure \textit{HashAggregate} nicht mehr im Abfrageplan
|
||||
|
|
@ -839,7 +842,7 @@ mehr möglich ist, da durch die definierten Indexe bei den aktuell möglichen So
|
|||
\textit{Index Scan} verwendet wird. Dies ist durch eine Überprüfung der Abfragepläne beweisbar, für diesen Fall wird
|
||||
die Abfrage aus \autoref{lst:explain-search-document} verwendet.
|
||||
|
||||
\begin{lstlisting}[language=SQL,caption={xxxl},label=lst:explain-search-document]
|
||||
\begin{lstlisting}[language=SQL,caption={Untersuchung searchdocument},label=lst:explain-search-document]
|
||||
explain (analyze)
|
||||
select sd.id, documentid, datetype, startyear, startmonth, startday
|
||||
, startdatestatus , endyear, endmonth, endday, enddatestatus
|
||||
|
|
@ -855,9 +858,10 @@ Ausgabe mit dem erstellten Index. Vor der zweiten Ausgabe wurde dieser Index dea
|
|||
sehen, dass bei der Verwendung des Index weniger Operation notwendig sind und damit auch die teure Sortierung
|
||||
eingespart werden konnte. Dies liegt daran, dass der Index entsprechend des Sortierkriterien definiert wurde und
|
||||
somit ist es möglich, direkt in dem Index die Elemente in der richtigen Reihenfolge zu ermitteln.
|
||||
Somit ist durch den Index der schnellstmögliche Zugriff gegeben.
|
||||
Somit ist durch den Index der schnellstmögliche Zugriff gegeben. Bei einem \textit{Seq Scan} ist die Ausgabe immer eine
|
||||
unsortierte Liste und benötigt daher im Nachgang die zusätzliche Sortierung.
|
||||
|
||||
\begin{lstlisting}[basicstyle=\scriptsize,caption={aa},label=lst:explain-search-document-output]
|
||||
\begin{lstlisting}[basicstyle=\scriptsize,caption={Abfrageplan searchdocument},label=lst:explain-search-document-output]
|
||||
Limit (cost=0.28..144.92 rows=400 width=948) (actual time=0.035..0.660 rows=400 loops=1)
|
||||
-> Index Scan Backward using idx_searchdocument_startdate on searchdocument sd (cost=0.28..1911.30 rows=5285 width=948) (actual time=0.033..0.593 rows=400 loops=1)
|
||||
Planning Time: 0.199 ms
|
||||
|
|
|
|||
|
|
@ -11,9 +11,10 @@ Es wurden die Konfigurationen der Caches von OpenJPA, \ac{JPA} und \ac{EJB} akti
|
|||
Caches, bei denen eine Größe angebbar ist, wurde zusätzlich mit der Anzahl variiert, um zu ermitteln, in welchem Umfang
|
||||
sich diese auswirken. Des Weiteren wird die Art der Programmierung für die Abfragen betrachtet, ob signifikante
|
||||
Unterschiede in der Performance und der Abarbeitung erkennbar sind. Als weiteren Punkt werden die Abfragen an die
|
||||
Datenbank untersucht, um zu ermitteln, ob diese durch Umstellung verbessert werden können. Abschließend werden die
|
||||
Datenbank untersucht, um zu ermitteln, ob diese durch Umstellung verbessert werden können. Danach werden die
|
||||
\textit{Materialized View} verwendet, um zu ermitteln, ob durch einen vorverdichteten und aufbereiteten Datenbestand
|
||||
die Abfragen beschleunigt werden können.
|
||||
die Abfragen beschleunigt werden können. Abschließend werden die Abfragen in der Datenbank betrachtet und auf ihre
|
||||
Optimierungspotentiale hin untersucht.
|
||||
|
||||
\section{Nutzerumfrage}
|
||||
\label{sec:evaluation:user-survey}
|
||||
|
|
@ -23,7 +24,7 @@ Personen zur Verfügung stehen, ist dies nicht zielführend. Daher ist die einzi
|
|||
wurde, ein rein technischer Ansatz.
|
||||
|
||||
\section{Umgestalten der Datenbanktabellen}
|
||||
\label{sec:evaluation:new-table}
|
||||
\label{sec:evaluation:new-table}
|
||||
|
||||
Hierfür wurde die aktuelle Datenstruktur untersucht, um zu überprüfen, ob eine Umgestaltung der Tabelle eine Verbesserung
|
||||
bringt. Die typische Optimierung ist die Normalisierung der Tabellenstruktur. Die Tabellenstruktur ist aktuell
|
||||
|
|
@ -31,7 +32,7 @@ schon normalisiert, daher kann hier nichts weiter optimiert werden.
|
|||
|
||||
Eine weitere Optimierungsstrategie besteht in der Denormalisierung, um sich die Verknüpfungen der Tabellen zu sparen.
|
||||
Dies ist in diesem Fall nicht anwendbar, da nicht nur 1:n Beziehungen vorhanden sind, sondern auch auch n:m Beziehungen.
|
||||
Dadurch würde sich die Anzahl der Dokumentenliste erhöhen.
|
||||
Dadurch würde sich fälschlicherweise die Anzahl der Dokumentenliste erhöhen.
|
||||
|
||||
\section{Statische Webseiten}
|
||||
\label{sec:evaluation:static-website}
|
||||
|
|
@ -81,7 +82,7 @@ hoch aus. Sobald bei den Anfragen aber häufig die zu ermittelnden Objekte sich
|
|||
aus dem Cache entfernt werden, fällt die Performance"=Verbesserung immer geringer aus.
|
||||
|
||||
Das Entfernen der Objekte kann zwar umgangen werden, indem die häufig abgefragten Objekte gepinnt werden, was aber
|
||||
den Speicherbedarf noch weiter erhöht, da diese Objekte nicht in die Zählung der Cache"=Objekte betrachtet werden.
|
||||
den Speicherbedarf noch weiter erhöht, da diese Objekte nicht in die Zählung der Cache"=Objekte miteinfliesen.
|
||||
Als größten Nachteil des Caches ist zu nennen, dass die notwendige Speichermenge ständig zur Verfügung gestellt
|
||||
werden muss. Damit ist immer ein gewisser Grundbedarf notwendig, da sich der Speicher bis zum eingestellten
|
||||
Grenzwert aufbaut und dann nicht mehr entleert wird. Gerade bei kleiner dimensionierten Servern stellt dies ein
|
||||
|
|
@ -114,7 +115,7 @@ Dadurch ist dieser Cache für eine Performance"=Verbesserung in dem Fall der Dok
|
|||
|
||||
Mit dem Ehcache konnte eine Verbesserung in der Performance erzielt werden. Im Vergleich zum Cache von OpenJPA ist
|
||||
die Verbesserung sehr ähnlich. Die Standardwerte dieses Caches sind gut vordefiniert, es wird für den aktuellen Fall
|
||||
keine Anpassung benötigt, um eine gute Performance zu bekommen. Hierbei ist natürlich das gleiche Problem wie in anderen
|
||||
keine Anpassung benötigt, um eine gute Performance zu erreichen. Hierbei ist natürlich das gleiche Problem wie in anderen
|
||||
Caches, dass beim Erreichen der Grenzen alte Objekte entfernt werden müssen.
|
||||
|
||||
Nach aktueller Beobachtung scheint die Verwaltung im Ehcache effizienter gestaltet zu sein als die des OpenJPA"=Caches.
|
||||
|
|
@ -147,7 +148,7 @@ Abfragen kein Unterschied festgestellt werden. Die Abfragen der beiden Systeme s
|
|||
identisch. Auch in der Übertragung der Daten aus der Datenbank in die Java"=Objekte konnte kein Unterschied in der
|
||||
Art und Geschwindigkeit festgestellt werden.
|
||||
|
||||
Ebenfalls sind die Möglichkeiten über der Optimierung über Hints identisch. In beiden Fällen haben die meisten Hints
|
||||
Ebenfalls sind die Möglichkeiten über der Optimierung durch Hints identisch. In beiden Fällen haben die meisten Hints
|
||||
keinen nennenswerten Einfluss auf die Laufzeit der Abfragen und Übertragung in die Java"=Objekte. Das sinnvolle Setzen
|
||||
von OptimizeResultCount, der FetchSize sowie der FetchBatchSize hilft dem Framework die Bearbeitung der Anfrage
|
||||
effizient abzuarbeiten, konnte aber in den gemessenen Laufzeiten nicht verifiziert werden.
|
||||
|
|
@ -159,7 +160,7 @@ Datenbank gestellt wird, sondern es werden alle Koautoren für die ermittelten D
|
|||
Zuordnung der Koautoren zu dem Dokument wird dann nun im Framework und nicht mehr durch die Datenbank durchgeführt.
|
||||
Diese Abarbeitung reduziert viele einzelne Abfragen und somit auch den entsprechend Overhead im Framework.
|
||||
|
||||
Folglich ist die Entscheidung der Technik für die Performance irrelevant und es kann das genutzt werden, was für
|
||||
Folglich ist die Entscheidung der Technik für die Performance irrelevant und es kann das genutzt werden, was für den
|
||||
jeweiligen Einsatzzweck besser beziehungsweise einfacher zu programmieren ist. Das Setzen der richtigen Hints wiederrum
|
||||
ist in beiden Fällen äußerst wichtig. Explizit bei der EagerFetchMode muss vorher darüber nachgedacht werden, wie viele
|
||||
abhängige Objekttypen es zu dieser Klasse gibt, welche dazu geladen werden sollen und von welcher Anzahl an Objekte
|
||||
|
|
@ -196,7 +197,7 @@ optimiert werden. Die Wandlung der Daten in \textit{\ac{HTML}}"=Objekte ist eine
|
|||
schwächeren Clients in kurzer Zeit durchführbar.
|
||||
|
||||
Als weiteren Punkt ist anzumerken, dass der Speicherbedarf des Webserver relativ konstant bleibt, ohne dass ein Cache
|
||||
verwendet wird. Der größte Unterschied zur Standardimplementierung ist die Verwendung von eigenen Codes, um die Objekte
|
||||
verwendet wird. Der größte Unterschied zur Standardimplementierung ist die Verwendung von eigenen Code, um die Objekte
|
||||
zu erstellen und zu befüllen und es nicht durch das OpenJPA"=Framework durchführen zu lassen.
|
||||
Dies legt den Schluss nahe, dass Probleme in der Speicherverwaltung der Objekte im OpenJPA"=Framework existieren.
|
||||
|
||||
|
|
@ -229,14 +230,14 @@ ist es laut Berechnung kostengünstiger mit einem \textit{Seq Scan}, was einem k
|
|||
entspricht, zu arbeiten.
|
||||
|
||||
Um dies zu optimieren, wurde über eine \textit{Common Table Expression} zuerst die eingeschränkten Datenzeilen
|
||||
ermittelt, dieser mit der Haupttabelle verknüpft und nun die anderen Tabellen dazugenommen. Hierdurch konnte die
|
||||
ermittelt, diese mit der Haupttabelle verknüpft und nun die anderen Tabellen dazugenommen. Hierdurch konnte die
|
||||
Zeilenanzahl während der Verarbeitung enorm verringert werden, wodurch einige der Verknüpfungen auf Indexzugriffe
|
||||
umgestellt wurden. Durch die Umstellung konnte die Abfragezeit um mehr als das dreifache reduziert werden.
|
||||
|
||||
Mit dieser Art der Umstellung können Abfragen optimiert werden, die für das Paging verwendet werden und die Abfrage aus
|
||||
mehrere Tabellen besteht. Das Wichtigste hierbei ist, dass die Bedingungen und die Sortierkriterien auf der
|
||||
Haupttabelle arbeiten. Wenn dem nicht so ist, müssen Joins in die \textit{Common Table Expression} mit aufgenommen
|
||||
werden und damit funktioniert die Reduzierung der Datensätze nicht mehr. Bei der Selektion einer Tabelle hat diese Art
|
||||
werden und damit funktioniert die Reduzierung der Datensätze nicht mehr so effizient. Bei der Selektion einer Tabelle hat diese Art
|
||||
der Optimierung keine Auswirkung, hier hilft nur das geschickte Setzen von Indexen auf die Tabelle, welche die
|
||||
Bedingungen und die Sortierkriterien beinhalten. Dies wurde mit der Untersuchung der Abfrage auf die
|
||||
\textit{Materialized View} bestätigt.
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@
|
|||
|
||||
Die Untersuchungen am Beispiel des Wedekind"=Projektes zeigen, dass mehrere Optimierungsmöglichkeiten in den
|
||||
Briefeditionen existieren. Für die Untersuchung wurde sich auf die Dokumentenliste beschränkt und anhand dieser
|
||||
die Optimierung implementiert, untersucht und jeweils mit der Ausgangsmessung vergleichen. Für die Messung wurden
|
||||
die Optimierung implementiert, untersucht und jeweils mit der Ausgangsmessung verglichen. Für die Messung wurden
|
||||
Skripte erstellt, welche auf dem gleichen Computer wie der Webserver und der Datenbankserver laufen, damit diese auch
|
||||
vergleichbar bleiben und externe Einflussfaktoren minimiert werden.
|
||||
|
||||
|
|
@ -24,7 +24,7 @@ Webseite wurden auf Grund von technischen Einschränkungen nicht weiterverfolgt.
|
|||
|
||||
Bei den Caches sind der Query"=Cache und der \ac{EJB}"=Cache nicht für die Optimierung verwendbar. Der Query"=Cache wird
|
||||
von OpenJPA nur verwendet, wenn die Abfrage keine Parameter besitzt, welche in der Dokumentliste verwendet werden
|
||||
mussten. Im \ac{EJB}"=Cache werden nicht die Objekt, sondern die Provider gespeichert, wodurch hier keine Auswirkung auf die
|
||||
müssen. Im \ac{EJB}"=Cache werden nicht die Objekt, sondern die Provider gespeichert, wodurch hier keine Auswirkung auf die
|
||||
Performance festgestellt werden konnte.
|
||||
|
||||
Anders sieht es bei dem OpenJPA"=Cache aus, dieser hat direkten Einfluss auf die Performance der Ermittlung der Daten
|
||||
|
|
@ -47,7 +47,7 @@ durch die Umstellung der Ermittlung der unterlagerten Daten durch Hints eine Opt
|
|||
bezweckt, dass die unterlagerten Daten nicht einzeln für jede Zeile ermittelt werden, sondern alle Daten auf einmal
|
||||
geladen werden und die Zuordnung der Datensätze im OpenJPA"=Framework durchgeführt wird.
|
||||
|
||||
Mit der Übernahme der \textit{Materialized View} aus dem Wedekind"=Projekt konnte erstmalig eine gute Optimierung
|
||||
Mit der Übernahme der \textit{Materialized View} aus dem Wedekind"=Projekt kann eine gute Optimierung
|
||||
beobachtet werden. Dies ist auf die einfachere Abfrage, die Reduzierung der Abfrage an den Datenbankserver und dass
|
||||
die Objekte im eigenen Code erstellt werden zurückzuführen und nicht auf das OpenJPA"=Framework. Hierbei konnte noch nachgewiesen
|
||||
werden, dass das Parsen der Json"=Daten, die die unterlagerten Objekte enthalten, den größten Teil der Zeit benötigen.
|
||||
|
|
@ -56,13 +56,14 @@ Auf Grund dessen wurde das Parsen der Json"=Daten auf den Client verschoben, was
|
|||
Für die Optimierung der Abfragen wurde die Hauptabfrage betrachtet. Bei dieser konnte anhand der visuellen Darstellung
|
||||
das Problem gut identifiziert werden. Durch die Verwendung einer \textit{Common Table Expression} wurde die Anzahl
|
||||
der Datensätze direkt am Anfang auf die angefragte Menge reduziert, wodurch die Anzahl der zu betrachteten Datensätze
|
||||
für die weiteren Verlinkungen enorm reduziert wurde. Somit konnte der Datenbankserver bei diesen Verlinkungen auf Indexe
|
||||
zugreifen und damit die Abfragen zusätzlich beschleunigen.
|
||||
für die weiteren Verlinkungen enorm reduziert wird. Somit konnte der Datenbankserver bei diesen Verlinkungen auf Indexe
|
||||
zurückgreifen und damit die Abfragen zusätzlich beschleunigen.
|
||||
|
||||
Die Untersuchungen zeigen, dass mehrere Möglichkeiten zur Optimierung existierten, um die Zugriffe auf die
|
||||
Briefeditionen zu beschleunigen und dass das größte Optimierungspotential in dem \ac{ORM} liegt. Welche der %dass oder das
|
||||
Optimierungen verwendet werden, liegt an der Komplexität der Abfrage und der bereitgestellten Ressourcen
|
||||
des Servers.
|
||||
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
|
||||
n:m"=Beziehungen besteht. Bei der Verwendung eines Caches sollte darauf geachtet werden, dass die notwendigen
|
||||
Ressourcen am Server bereitgestellt werden können und es wird empfohlen auf den Ehcache umzustellen.
|
||||
|
||||
\section{Ausblick}
|
||||
\label{sec:summary_and_outlook:outlook}
|
||||
|
|
@ -77,6 +78,6 @@ werden. Bei den Umstellungen der Abfragen ist die größte Stärke, wenn die Anz
|
|||
könnte.
|
||||
|
||||
Dadurch zeigt sich, dass die Untersuchung auf Ebene der \ac{ORM} noch nicht abgeschlossen ist. Weitere Untersuchungen
|
||||
von anderen \ac{ORM} könnten wie in \ref{sec:evaluation:materialized-view} angedeutet das Speicherproblem lösen,
|
||||
von anderen \ac{ORM} könnten wie in \autoref{sec:evaluation:materialized-view} angedeutet das Speicherproblem lösen,
|
||||
sowie eine generelle Optimierung der Webseite zur Folge haben. Eine eigenständige Implementierung eines einfachen
|
||||
\ac{ORM} wäre auch in Betracht zu ziehen, solange sich die Komplexität der Daten"=Struktur nicht erhöht.
|
||||
\ac{ORM} wäre auch in Betracht zu ziehen, solange sich die Komplexität der Daten"=Struktur nicht erhöht.
|
||||
|
|
|
|||
|
|
@ -90,6 +90,15 @@
|
|||
urldate = {2024-09-20}
|
||||
},
|
||||
|
||||
@online{DFGProje43:online,
|
||||
author = {DFG-Projekt},
|
||||
title = {DFG-Projekt: Edition der Korrespondenz Frank Wedekinds als Online-Volltextdatenbank - FernUniversität in Hagen},
|
||||
url = {https://www.fernuni-hagen.de/dbis/forschung/wedekind.shtml},
|
||||
month = {},
|
||||
year = {},
|
||||
urldate = {2024-09-28}
|
||||
},
|
||||
|
||||
@online{Dokument53:online,
|
||||
author = {},
|
||||
title = {Dokumentenliste mit Native Query und Materialized View (b1f4c93d) · Commits · Wedekind / briefdb 2.0 · GitLab},
|
||||
|
|
|
|||
BIN
thesis.pdf
BIN
thesis.pdf
Binary file not shown.
Loading…
Reference in a new issue