Daily CheckIn

This commit is contained in:
marcodn 2024-09-29 11:02:28 +02:00
parent e60246828e
commit 409d2c4047
7 changed files with 36 additions and 36 deletions

View file

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

View file

@ -34,9 +34,9 @@ Für die Wartungsaufgaben wie VACUUM oder dem Erstellen von Indexen wird die Beg
\texttt{maintenance\_work\_mem} gesetzt. Dieser Wert sollte 5\% des verfügbaren Arbeitsspeicher entsprechen und größer \texttt{maintenance\_work\_mem} gesetzt. Dieser Wert sollte 5\% des verfügbaren Arbeitsspeicher entsprechen und größer
als \texttt{work\_mem} sein. als \texttt{work\_mem} sein.
Nachfolgend wird mit dem Systemtools, wie den Konsolenanwendungen \textit{htop} und \textit{free}, die Auslastung des Servers Nachfolgend wird mit den Systemtools, wie den Konsolenanwendungen \textit{htop} und \textit{free}, die Auslastung des Servers
überprüft. Hierbei ist die CPU"=Leistung, der aktuell genutzte Arbeitsspeicher, sowie die Zugriffe auf die Festplatte überprüft. Hierbei ist die CPU"=Leistung, der aktuell genutzte Arbeitsspeicher, sowie die Zugriffe auf die Festplatte
die wichtigen Faktoren zur Bewertung. %TODO wichtigsten? die wichtigsten Faktoren zur Bewertung.
Die CPU"=Leistung sollte im Schnitt 70\% nicht überschreiten, für kurze Spitzen wäre dies zulässig, um die gestellten 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 Anfragen schnell genug abarbeiten zu können. Daher soll verhindert werden, dass der Server an seiner Leistungsgrenze
@ -124,8 +124,8 @@ und dessen Ausführungszeit ermittelt.
Zusätzlich werden im PostgreSQL"=Server Optimierungen vorgenommen, darunter zählen die \textit{Materialized View}, welche eine 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 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 diese viel schneller abgefragt werden können. Zusätzlich werden die \textit{Cached queries} überprüft, ob diese eine Verbesserung
der Performance und damit eine Reduzierung der Abfragedauern erreichen. der Performance ergeben 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. Wichtig hierbei ist, dass die Webseite immer vollständig gerendert vom Server an den Client übertragen wird.

View file

@ -48,7 +48,7 @@ in die Log"=Datei eingetragen. Durch die Kennung können die Zeiten im Nachgang
ausgewertet werden. ausgewertet werden.
Zusätzlich wird noch eine Implementierung der zugehörigen Factory"=Klasse \texttt{ViewDeclarationLanguageFactory} Zusätzlich wird noch eine Implementierung der zugehörigen Factory"=Klasse \texttt{ViewDeclarationLanguageFactory}
benötigt. Durch diese Factory"=Klasse wird der eigentlichen Wrapper mit der Performance-Messung in die Bearbeitungsschicht benötigt. Durch diese Factory"=Klasse wird der eigentlichen Wrapper mit der Performance"=Messung in die Bearbeitungsschicht
eingehängt. Diese Implementierung wird dann noch in der \texttt{faces-config.xml} eingetragen, wie das in eingehängt. Diese Implementierung wird dann noch in der \texttt{faces-config.xml} eingetragen, wie das in
\autoref{lst:activate-factory} aufgezeigt wird, damit die Factory durch das System aufgerufen wird. \autoref{lst:activate-factory} aufgezeigt wird, damit die Factory durch das System aufgerufen wird.
@ -78,7 +78,7 @@ log_rotation_size = 100MB
Über die Konfiguration unter \autoref{lst:postgresql_logconf} wird definiert welche Werte protokolliert werden. Die Ü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 wichtigste Einstellung ist \texttt{log\_min\_duration\_statement}, diese definiert, ab welcher Laufzeit eine Abfrage
protokolliert werden soll. Mit dem Wert 0 werden alle Abfragen protokolliert. Alle weiteren Einstellungen sind so protokolliert werden soll. Mit dem Wert 0 werden alle Abfragen protokolliert. Alle weiteren Einstellungen sind so
gesetzt, dass nicht unnötige Abfragen für die spätere Auswertung mit \textit{pgBadger} protokolliert werden. gesetzt, dass nur notwendige Abfragen für die spätere Auswertung mit \textit{pgBadger} protokolliert werden.
Zusätzlich ist die Einstellung \texttt{log\_temp\_files} auf 0 zu setzen, dadurch werden alle erzeugten temporären 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 Dateien und ihre Größe ebenfalls protokolliert. Diese Dateien entstehen, wenn der temporäre Puffer für die Abfrage
nicht ausreicht und die Zwischenergebnisse ausgelagert werden müssen. nicht ausreicht und die Zwischenergebnisse ausgelagert werden müssen.
@ -102,7 +102,7 @@ log_timezone = 'Europe/Berlin'
\section{Prüfung von Abfragen} \section{Prüfung von Abfragen}
\label{sec:performance-checking:sql-query-checking} \label{sec:performance-checking:sql-query-checking}
Das Untersuchen der protokollierten Abfragen auf Performance Optimierungen ist ein weiterer Bestandteil dieser Arbeit. Das Untersuchen der protokollierten Abfragen auf Performance"=Optimierungen ist ein weiterer Bestandteil dieser Arbeit.
Das Schlüsselwort \texttt{EXPLAIN} ist im PostgreSQL vorhanden, um den Abfrageplan einer Abfrage zu ermitteln und Das Schlüsselwort \texttt{EXPLAIN} ist im PostgreSQL vorhanden, um den Abfrageplan einer Abfrage zu ermitteln und
darzustellen, um diese anschließend zu untersuchen. Der Abfrageplan ist als Baum dargestellt, bei welchem die Knoten die darzustellen, um diese anschließend zu untersuchen. Der Abfrageplan ist als Baum dargestellt, bei welchem die Knoten die
unterschiedlichen Zugriffsarten darstellen. Die Verbindung der Knoten und der Aufbau zeigt die Operationen, wie unterschiedlichen Zugriffsarten darstellen. Die Verbindung der Knoten und der Aufbau zeigt die Operationen, wie
@ -140,17 +140,17 @@ Vergleichsoperation auf die Tabellenspalte zugegriffen wird.
Um größere und aufwendigere Abfragen zu optimieren, bietet der PostgreSQL noch die Möglichkeit von Um größere und aufwendigere Abfragen zu optimieren, bietet der PostgreSQL noch die Möglichkeit von
\textit{Materialized View}. Diese sind sehr ähnlich zu den Sichten, zusätzlich werden aber die Ergebnisse in einer \textit{Materialized View}. Diese sind sehr ähnlich zu den Sichten, zusätzlich werden aber die Ergebnisse in einer
tabellenähnlichen Form abgespeichert, somit sind die Zugriff auf diese Daten häufig performanter als die eigentliche Abfrage. tabellenähnlichen Form abgespeichert, somit sind die Zugriff auf diese Daten häufig performanter als die eigentliche Abfrage.
Daher muss abgewägt werden, ob die Performance-Verbesserung trotz der zusätzlichen Aktualisierung des Datenbestandes Daher muss abgewägt werden, ob die Performance"=Verbesserung trotz der zusätzlichen Aktualisierung des Datenbestandes
als sinnvoll erachtet werden kann. als sinnvoll erachtet werden kann.
Zusätzlich kann über die Systemtabelle \texttt{pg\_statistic} oder die lesbarere Systemsicht \texttt{pg\_stats} die Zusätzlich können über die Systemtabelle \texttt{pg\_statistic} oder die lesbarere Systemsicht \texttt{pg\_stats} die
aktuellen statistischen Informationen über eine Tabelle und deren Spalten ermittelt werden. In dieser Tabelle werden 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 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 \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 weitere gesammelt und für die Erstellung der Abfragepläne verwendet \citep{PostgreS39:online}. Diese Information
sollte vor dem erstellen eines Index betrachtet werden. sollte vor dem erstellen eines Index betrachtet werden.
Durch das Kommando \texttt{CREATE STATISTICS} können diese Informationen erweitert werden, um das erstellen des Abfrageplans Durch das Kommando \texttt{CREATE STATISTICS} können diese Informationen erweitert werden, um das Erstellen des Abfrageplans
zu verbessern. Das Aktivieren der zusätzlichen Statistiken sollte immer in Verbindung mit der Überprüfung des 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 Abfrageplans durchgeführt werden, um zu ermitteln inwieweit die Anpassung zu einer Optimierung und keiner
Verschlechterung führt. Verschlechterung führt.

View file

@ -16,8 +16,8 @@ gedauert hat. Die weiteren Aufrufe benötigen im Durchschnitt noch 600 ms. Beim
Server nicht mehr reagiert und im Log ist ein \textit{OutOfMemoryError} protokolliert worden. Server nicht mehr reagiert und im Log ist ein \textit{OutOfMemoryError} protokolliert worden.
Nach einem Neustart des Servers konnte das gleiche Verhalten wieder reproduziert werden. Daraufhin ist eine Erweiterung 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 des Test"=Scripts notwendig, um die aktuelle 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 Auswertung zeigt, dass der Server mit circa 1500 MB RSS Nutzung an seine Grenzen stößt. Diese Grenze wird durch die
Konfigurationsänderung im Payara-Server von \texttt{-Xmx512m} auf \texttt{-Xmx4096m} nach oben verschoben. Nun werden 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} 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 in der Log-Datei protokolliert und der Server verwendet nun circa 4700 MB RSS. Bei allen Tests war noch mehr als die
@ -68,10 +68,10 @@ konfigurierten Cache Einstellungen. Einige dieser Abfragen sind durch das Erstel
\textit{searchreference} und \textit{searchfulltext} erklärbar. Zusätzlich ist noch ein zyklischer Dienst \textit{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 \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 und entsprechend einige Abfragen an die Datenbank absetzt. Da weder die Sichten noch der Dienst für die Dokumentenliste
benötigt werden, ist der Dienst und das Erstellen im Code für die weiteren Tests deaktiviert. benötigt werden, werden der Dienst und das Erstellen im Code für die weiteren Tests deaktiviert.
Da die Abfragezeiten auf der Datenbank zu gering sind, um eine Verbesserung feststellen zu können, wird für den Da die Abfragezeiten auf der Datenbank zu gering sind, um eine Verbesserung feststellen zu können, wird für den
PostgreSQL und den Payara"=Server ein Docker"=Container erzeugt und diese limitiert. Die Konfiguration ist in PostgreSQL und den Payara"=Server ein Docker"=Container erzeugt und dieser limitiert. Die Konfiguration ist in
\autoref{ap:docker_config} beschrieben. \autoref{ap:docker_config} beschrieben.
Mit dem neuen Aufbau ergibt sich eine neue Messung. Für den Speicherbedarf wird nun nicht mehr der benutzte Mit dem neuen Aufbau ergibt sich eine neue Messung. Für den Speicherbedarf wird nun nicht mehr der benutzte
@ -156,7 +156,7 @@ wachsenden Speicherbedarfs nur nicht erklärt werden.
Bei einer erhöhten Cache"=Größe, von 1000 auf 10000, zeigt sich auf den ersten Blick ein noch besseres Bild ab, wie in Bei einer erhöhten Cache"=Größe, von 1000 auf 10000, zeigt sich auf den ersten Blick ein noch besseres Bild ab, wie in
\autoref{tbl:measure-ojpa-active-bigger} ersichtlich ist. Der erste Aufruf entspricht der Laufzeit mit geringerer \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 Cache"=Größe, aber schon die Anfragen an die Datenbank gehen drastisch zurück. Bei den weiteren Aufrufen werden im
Schnitt nun nur noch 6 Anfragen pro Seitenaufruf an die Datenbank gestellt, wodurch die Laufzeit im Schnitt nochmal Schnitt nun nur noch sechs Anfragen pro Seitenaufruf an die Datenbank gestellt, wodurch die Laufzeit im Schnitt nochmal
um 100 ms beschleunigt werden kann. um 100 ms beschleunigt werden kann.
\begin{table}[H] \begin{table}[H]
@ -289,8 +289,8 @@ benötigt.
\label{sec:performance-investigation-application:caching-ejb} \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 Die Cache"=Einstellungen des \ac{EJB} sind in der Admin-Oberfläche des Payara-Servers zu erreichen. Unter dem Punkt
Configurations $\Rightarrow$ server"=config $\Rightarrow$ \ac{EJB} Container wird zum einen die minimalen und maximalen Configurations $\Rightarrow$ server"=config $\Rightarrow$ \ac{EJB} Container werden 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 Größen des Pools definiert. Zum anderen werden an dieser Stelle die maximale Größe des Caches und die Größe der
Erweiterung definiert. Erweiterung definiert.
Anhand der Auswertung der \autoref{tbl:measure-ejb-cache-active} ist ersichtlich, dass der \ac{EJB}"=Cache keine Anhand der Auswertung der \autoref{tbl:measure-ejb-cache-active} ist ersichtlich, dass der \ac{EJB}"=Cache keine
@ -340,7 +340,7 @@ ORDER BY d.documentId ASC
\end{lstlisting} \end{lstlisting}
Der dazugehörige Code im Server ist in \autoref{lst:jpql-document-list} zu finden und zeigt wie die benannte Anfrage Der dazugehörige Code im Server ist in \autoref{lst:jpql-document-list} zu finden und zeigt wie die benannte Anfrage
aufgerufen und die ermittelt Daten übernimmt. Zusätzlich wird an dieser Stelle die Parameter versorgt, die Grenzwerte aufgerufen und die ermittelten Daten übernimmt. Zusätzlich werden an dieser Stelle die Parameter versorgt, die Grenzwerte
der Paginierung und die Hints hinterlegt. der Paginierung und die Hints hinterlegt.
\begin{lstlisting}[language=Java,caption={Java JPQL Dokumentenliste},label=lst:jpql-document-list] \begin{lstlisting}[language=Java,caption={Java JPQL Dokumentenliste},label=lst:jpql-document-list]
@ -358,7 +358,7 @@ if(myResultList != null && !myResultList.isEmpty()) {
} }
\end{lstlisting} \end{lstlisting}
Da dieser Code direkt so aus dem Projekt stammt, wird hierfür keine gesonderte Zeitmessung durchgeführt, da diese der Da dieser Code direkt aus dem Projekt stammt, wird hierfür keine gesonderte Zeitmessung durchgeführt, da diese der
Messung aus \autoref{tbl:measure-without-cache} entspricht. Messung aus \autoref{tbl:measure-without-cache} entspricht.
Für die Optimierung wurden noch zusätzlich die Hints \texttt{openjpa.""hint.""OptimizeResultCount}, Für die Optimierung wurden noch zusätzlich die Hints \texttt{openjpa.""hint.""OptimizeResultCount},
@ -398,7 +398,7 @@ in diesem Fall nicht zu verwenden.
\section{Abfragen Criteria API} \section{Abfragen Criteria API}
\label{sec:performance-investigation-application:query-criteria-api} \label{sec:performance-investigation-application:query-criteria-api}
Für die Criteria API wird die Abfrage nicht in einem \ac{SQL}"=Dialekt beschrieben, hierbei werden über Attribute die Für die Criteria API wird die Abfrage nicht in einem \ac{SQL}"=Dialekt geschrieben, hierbei werden über Attribute die
Verlinkung zur Datenbank durchgeführt. An der Klasse selbst wird der Tabellenname definiert und an den Attributen die 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 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. versorgt werden, wie es in \autoref{lst:criteria-api} gezeigt wird.
@ -454,7 +454,7 @@ Abfragen in den Java-Objekten fast identisch sind. In der Datenbank sind die Anf
\label{tbl:measure-criteria-api} \label{tbl:measure-criteria-api}
\end{table} \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 Implementierungen ohne Bedenken gegeneinander ausgetauscht werden, und die verwendet werden, die für den Anwendungsfall
einfacher umzusetzen ist. einfacher umzusetzen ist.
@ -630,7 +630,7 @@ WHERE d.validuntil > NOW()
AND d.ispublishedindb = true; AND d.ispublishedindb = true;
\end{lstlisting} \end{lstlisting}
Nach den Anpassungen haben sich dann die Werte aus \autoref{tbl:measure-materialized-view-ext} ergeben. Diese Werte Nach den Anpassungen haben sich die Werte aus \autoref{tbl:measure-materialized-view-ext} ergeben. Diese Werte
zeigen nur minimale Unterschiede in den Zeiten, diese sind auf Messtoleranzen zurückzuführen. zeigen nur minimale Unterschiede in den Zeiten, diese sind auf Messtoleranzen zurückzuführen.
\begin{table}[H] \begin{table}[H]
@ -799,8 +799,8 @@ von \textit{Index Scan}.
Die beste Optimierung hierbei ist, die Menge der Datensätze so früh wie möglich einzuschränken. Da die Verwendung von Die beste Optimierung hierbei ist, die Menge der Datensätze so früh wie möglich einzuschränken. Da die Verwendung von
\texttt{order by} innerhalb eines Sub"=Selects nicht erlaubt ist, wird hierfür eine \textit{Common Table Expression} \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 verwendet, wie es in \autoref{lst:explain-optimize-cte} zu sehen ist. Zusätzlich wird noch ein Index auf die
\textit{document}"=Tabelle für die Spalten der Bedingung und der Sortierung gesetzt, wie in \textit{document}"=Tabelle für die Spalten der Bedingung und der Sortierung erstellt, wie in
\autoref{lst:explain-optimize-cte-idx} zu sehen, damit in der \textit{Common Table Expression} nur der Index verwendet \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. werden kann und kein zusätzlicher Zugriff in die Tabelle notwendig ist.
@ -859,7 +859,7 @@ sehen, dass bei der Verwendung des Index weniger Operation notwendig sind und da
eingespart werden konnte. Dies liegt daran, dass der Index entsprechend des Sortierkriterien definiert wurde und 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 es möglich, direkt in dem Index die Elemente in der richtigen Reihenfolge zu ermitteln.
Somit ist durch den Index der schnellstmögliche Zugriff gegeben. Bei einem \textit{Seq Scan} ist die Ausgabe immer eine Somit ist durch den Index der schnellstmögliche Zugriff gegeben. Bei einem \textit{Seq Scan} ist die Ausgabe immer eine
unsortierte Liste und benötigt daher im Nachgang die zusätzliche Sortierung. unsortierte Liste und benötigt daher im Nachgang eine zusätzliche Sortierung.
\begin{lstlisting}[basicstyle=\scriptsize,caption={Abfrageplan searchdocument},label=lst:explain-search-document-output] \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) Limit (cost=0.28..144.92 rows=400 width=948) (actual time=0.035..0.660 rows=400 loops=1)

View file

@ -32,7 +32,7 @@ schon normalisiert, daher kann hier nichts weiter optimiert werden.
Eine weitere Optimierungsstrategie besteht in der Denormalisierung, um sich die Verknüpfungen der Tabellen zu sparen. 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. Dies ist in diesem Fall nicht anwendbar, da nicht nur 1:n Beziehungen vorhanden sind, sondern auch auch n:m Beziehungen.
Dadurch würde sich fälschlicherweise die Anzahl der Dokumentenliste erhöhen. Dadurch erhöht sich fälschlicherweise die Anzahl der Dokumentenliste.
\section{Statische Webseiten} \section{Statische Webseiten}
\label{sec:evaluation:static-website} \label{sec:evaluation:static-website}
@ -148,7 +148,7 @@ Abfragen kein Unterschied festgestellt werden. Die Abfragen der beiden Systeme s
identisch. Auch in der Übertragung der Daten aus der Datenbank in die Java"=Objekte konnte kein Unterschied in der identisch. Auch in der Übertragung der Daten aus der Datenbank in die Java"=Objekte konnte kein Unterschied in der
Art und Geschwindigkeit festgestellt werden. Art und Geschwindigkeit festgestellt werden.
Ebenfalls sind die Möglichkeiten über der Optimierung durch Hints identisch. In beiden Fällen haben die meisten Hints Ebenfalls sind die Möglichkeiten der Optimierung durch die Hints identisch. In beiden Fällen haben die meisten Hints
keinen nennenswerten Einfluss auf die Laufzeit der Abfragen und Übertragung in die Java"=Objekte. Das sinnvolle Setzen 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 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. effizient abzuarbeiten, konnte aber in den gemessenen Laufzeiten nicht verifiziert werden.
@ -197,7 +197,7 @@ optimiert werden. Die Wandlung der Daten in \textit{\ac{HTML}}"=Objekte ist eine
schwächeren Clients in kurzer Zeit durchführbar. 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 Als weiteren Punkt ist anzumerken, dass der Speicherbedarf des Webserver relativ konstant bleibt, ohne dass ein Cache
verwendet wird. Der größte Unterschied zur Standardimplementierung ist die Verwendung von eigenen Code, um die Objekte verwendet wird. Der größte Unterschied zur Standardimplementierung ist die Verwendung von eigenen Codes, um die Objekte
zu erstellen und zu befüllen und es nicht durch das OpenJPA"=Framework durchführen zu lassen. 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. Dies legt den Schluss nahe, dass Probleme in der Speicherverwaltung der Objekte im OpenJPA"=Framework existieren.
@ -229,15 +229,15 @@ sind. Für den PostgreSQL
ist es laut Berechnung kostengünstiger mit einem \textit{Seq Scan}, was einem kompletten Durchlaufen der Tabelle ist es laut Berechnung kostengünstiger mit einem \textit{Seq Scan}, was einem kompletten Durchlaufen der Tabelle
entspricht, zu arbeiten. entspricht, zu arbeiten.
Um dies zu optimieren, wurde über eine \textit{Common Table Expression} zuerst die eingeschränkten Datenzeilen Um dies zu optimieren, werden über eine \textit{Common Table Expression} zuerst die eingeschränkten Datenzeilen
ermittelt, diese mit der Haupttabelle verknüpft und nun die anderen Tabellen dazugenommen. Hierdurch konnte die ermittelt, diese mit der Haupttabelle verknüpft und anschließend die anderen Tabellen hinzugenommen. Hierdurch kann die
Zeilenanzahl während der Verarbeitung enorm verringert werden, wodurch einige der Verknüpfungen auf Indexzugriffe Zeilenanzahl während der Verarbeitung enorm verringert werden, wodurch einige der Verknüpfungen auf Indexzugriffe
umgestellt wurden. Durch die Umstellung konnte die Abfragezeit um mehr als das dreifache reduziert werden. umgestellt werden. Durch die Umstellung kann die Abfragezeit um mehr als das dreifache reduziert werden.
Mit dieser Art der Umstellung können Abfragen optimiert werden, die für das Paging verwendet werden und die Abfrage aus 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 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 Haupttabelle arbeiten. Wenn dem nicht so ist, müssen Joins in die \textit{Common Table Expression} mit aufgenommen
werden und damit funktioniert die Reduzierung der Datensätze nicht mehr so effizient. Bei der Selektion einer Tabelle hat diese Art werden und damit funktioniert die Reduzierung der Datensätze weniger effizient. Bei der Selektion einer Tabelle hat diese Art
der Optimierung keine Auswirkung, hier hilft nur das geschickte Setzen von Indexen auf die Tabelle, welche die der Optimierung keine Auswirkung, hier hilft nur das geschickte Setzen von Indexen auf die Tabelle, welche die
Bedingungen und die Sortierkriterien beinhalten. Dies wurde mit der Untersuchung der Abfrage auf die Bedingungen und die Sortierkriterien beinhalten. Dies wird mit der Untersuchung der Abfrage auf die
\textit{Materialized View} bestätigt. \textit{Materialized View} bestätigt.

View file

@ -61,7 +61,7 @@ zurückgreifen und damit die Abfragen zusätzlich beschleunigen.
Die Untersuchungen zeigen, dass mehrere Möglichkeiten zur Optimierung existierten, um die Zugriffe auf die Die Untersuchungen zeigen, dass mehrere Möglichkeiten zur Optimierung existierten, um die Zugriffe auf die
Briefeditionen zu beschleunigen und dass das größte Optimierungspotential in dem \ac{ORM} liegt. Die Umstellung auf Briefeditionen zu beschleunigen und dass das größte Optimierungspotential in dem \ac{ORM} liegt. Die Umstellung auf
eine \textit{Materialized View} ist eine sinnvolle Wahl, wenn die Abfrage der Daten komplexer ist oder aus mehreren eine \textit{Materialized View} ist eine sinnvolle Wahl, wenn die Abfrage der Daten komplexer ausfällt oder aus mehreren
n:m"=Beziehungen besteht. Bei der Verwendung eines Caches sollte darauf geachtet werden, dass die notwendigen 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. Ressourcen am Server bereitgestellt werden können und es wird empfohlen auf den Ehcache umzustellen.
@ -80,4 +80,4 @@ könnte.
Dadurch zeigt sich, dass die Untersuchung auf Ebene der \ac{ORM} noch nicht abgeschlossen ist. Weitere Untersuchungen Dadurch zeigt sich, dass die Untersuchung auf Ebene der \ac{ORM} noch nicht abgeschlossen ist. Weitere Untersuchungen
von anderen \ac{ORM} könnten wie in \autoref{sec:evaluation:materialized-view} angedeutet das Speicherproblem lösen, 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 sowie eine generelle Optimierung der Webseite zur Folge haben. Eine eigenständige Implementierung eines einfachen
\ac{ORM} wäre auch in Betracht zu ziehen, solange sich die Komplexität der Daten"=Struktur nicht erhöht. \ac{ORM} wäre ebenfalls in Betracht zu ziehen, solange sich die Komplexität der Daten"=Struktur nicht erhöht.

Binary file not shown.