Daily CheckIn
This commit is contained in:
marcodn
parent
c71b503424
commit
7ae5b1ce95
8 changed files with 193 additions and 102 deletions
1
.vscode/settings.json
vendored
1
.vscode/settings.json
vendored
|
|
@ -84,6 +84,7 @@
|
|||
"fmtutil",
|
||||
"gpasswd",
|
||||
"hcap",
|
||||
"heapsort",
|
||||
"historicalperson",
|
||||
"ispublishedindb",
|
||||
"javax",
|
||||
|
|
|
|||
|
|
@ -123,7 +123,7 @@ Die Abfragen werden ebenfalls untersucht und mit verschiedenen Methoden optimier
|
|||
SQL"=Anfragen umgestellt und die Ausführungszeiten überprüft. Ebenfalls werden die Abfragen durch Criteria API erzeugt
|
||||
und dessen Ausführungszeit ermittelt.
|
||||
|
||||
Zusätzlich werden im SQL-Server Optimierungen vorgenommen, darunter zählen die Materialisierten Sichten, welche eine
|
||||
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 noch vorberechneten 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.
|
||||
|
|
|
|||
|
|
@ -132,10 +132,11 @@ zusammengesetzten Index von Bedeutung. Als Grundlage sollte hier mit der Spalte
|
|||
Einschränkung durchführt. Zusätzlich muss die Art des Index definiert werden, welche davon abhängig ist, mit welcher
|
||||
Vergleichsoperation auf die Tabellenspalte zugegriffen wird.
|
||||
|
||||
Um größere und aufwendige Abfragen zu optimieren, bietet der PostgreSQL noch die Möglichkeiten von Materialisierten
|
||||
Sichten. Diese sind sehr ähnlich zu Sichten, speichern zusätzlich die Ergebnisse in einer tabellenähnlichen Form ab.
|
||||
Somit sind die Zugriff auf diese Daten häufig performanter als die eigentliche Abfrage. Die Performance wird durch
|
||||
die zusätzliche Aktualisierung des Datenbestand erkauft und muss daher abgewägt werden, was sinnvoller ist.
|
||||
Um größere und aufwendige Abfragen zu optimieren, bietet der PostgreSQL noch die Möglichkeiten von
|
||||
\textit{Materialized View}. Diese sind sehr ähnlich zu Sichten, speichern zusätzlich die Ergebnisse in einer
|
||||
tabellenähnlichen Form ab. Somit sind die Zugriff auf diese Daten häufig performanter als die eigentliche Abfrage.
|
||||
Die Performance wird durch die zusätzliche Aktualisierung des Datenbestand erkauft und muss daher abgewägt werden,
|
||||
was sinnvoller ist.
|
||||
|
||||
\mytodos{das doch wieder raus? oder nur das mit create statistics drin lassen}
|
||||
|
||||
|
|
|
|||
|
|
@ -3,6 +3,8 @@
|
|||
\chapter{Performance-Untersuchung der Anwendung}
|
||||
\label{ch:performance-investigation-application}
|
||||
|
||||
\mytodos{Sortierung nochmal überlegen, sinnvoller wäre doch anhand der Schichten aus Kapitel 2}
|
||||
|
||||
Nun werden die unterschiedlichen Schichten betrachtet und möglichen Performance"=Verbesserungen untersucht und deren
|
||||
Vor"= und Nachteile herausgearbeitet.
|
||||
|
||||
|
|
@ -64,7 +66,7 @@ gehalten werden sollten.
|
|||
|
||||
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 Abfragen sind durch das Erstellen der Materialisierten Sichten
|
||||
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
|
||||
|
|
@ -112,6 +114,8 @@ zu laden, und in die Java-Objekte umzuformen.
|
|||
\section{Umgestalten der Datenbanktabellen}
|
||||
\label{sec:performance-investigation-application:new-table}
|
||||
|
||||
\mytodos{Sollte das nicht auch in die Evaluierung?}
|
||||
|
||||
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.
|
||||
|
|
@ -476,8 +480,8 @@ Geschwindigkeit optimiert.
|
|||
\section{Materialized Views}
|
||||
\label{sec:performance-investigation-application:materialized-views}
|
||||
|
||||
Materialized Views sind Sichten in der Datenbank, die beim erstellen der Sicht den aktuellen Zustand ermitteln und
|
||||
Zwischenspeichern. Somit wird beim Zugriff auf diese Sichten, nicht die hinterlegte Abfrage ausgeführt, sondern auf
|
||||
\textit{Materialized Views} sind Sichten in der Datenbank, die beim erstellen der Sicht den aktuellen Zustand ermitteln
|
||||
und Zwischenspeichern. Somit wird beim Zugriff auf diese Sichten, nicht die hinterlegte Abfrage ausgeführt, sondern auf
|
||||
die gespeicherten Daten zugegriffen. Dies ist gerade bei vielen Joins von Vorteil. Zusätzlich können auf solchen
|
||||
Sichten auch Indexe erstellt werden, um noch effektiver die Abfragen bearbeiten zu können.
|
||||
|
||||
|
|
@ -485,12 +489,12 @@ Der größte Nachteil dieser Sichten ist, dass sie zyklisch oder bei Datenänder
|
|||
läuft der Datenbestand der Sicht und der zugrundeliegenden Abfrage auseinander. Da die Hauptarbeiten auf der Webseite
|
||||
die Abfrage der Daten ist, und nicht das editieren, kann dieser Nachteil bei entsprechender Optimierung ignoriert werden.
|
||||
|
||||
In diesem Test wurde die aktuelle Implementierung aus dem Wedekind"=Projekt der Materialized View inklusive der Trigger
|
||||
und der \textit{SearchDocument}"=Klasse übernommen \citep{Dokument53:online}. Wie in \autoref{lst:sql-materialized-view}
|
||||
zu sehen, wurden zur Standard"=Abfrage, die sonst zusätzlichen Abfragen als direkte Sub"=Selects mit integriert. Der
|
||||
Datenbestand dieser Sub"=Selects, wird im Json"=Format angegeben, damit bei den Koautoren und den Adressen mehrere
|
||||
Datensätze in einer Zeile zurückgegeben werden können. Ohne diese Technik würde sich die Anzahl der Dokumente
|
||||
vervielfachen.
|
||||
In diesem Test wurde die aktuelle Implementierung aus dem Wedekind"=Projekt der \textit{Materialized View} inklusive
|
||||
der Trigger und der \textit{SearchDocument}"=Klasse übernommen \citep{Dokument53:online}. Wie in
|
||||
\autoref{lst:sql-materialized-view} zu sehen, wurden zur Standard"=Abfrage, die sonst zusätzlichen Abfragen als
|
||||
direkte Sub"=Selects mit integriert. Der Datenbestand dieser Sub"=Selects, wird im Json"=Format angegeben, damit bei
|
||||
den Koautoren und den Adressen mehrere Datensätze in einer Zeile zurückgegeben werden können. Ohne diese Technik würde
|
||||
sich die Anzahl der Dokumente vervielfachen.
|
||||
|
||||
\begin{lstlisting}[language=SQL,caption={SQL Materialized View},label=lst:sql-materialized-view]
|
||||
CREATE MATERIALIZED VIEW searchdocument AS
|
||||
|
|
@ -624,9 +628,9 @@ vorhanden Elemente die die Liste der Dokumente anzeigt kopiert und auf die \text
|
|||
\label{tbl:measure-materialized-view}
|
||||
\end{table}
|
||||
|
||||
Wie in \autoref{tbl:measure-materialized-view} zu sehen, bringt die Verwendung der Materialized View eine Verbesserung
|
||||
in verschiedenen Punkten. Zum einen ist eine Verbesserung der Aufrufzeiten zu erkennen, zusätzlich fällt der
|
||||
Speicheranstieg weniger stark aus. Die Verbesserung der Aufrufzeiten lässt sich zusätzlich erklären, dass hier nun
|
||||
Wie in \autoref{tbl:measure-materialized-view} zu sehen, bringt die Verwendung der \textit{Materialized View} eine
|
||||
Verbesserung in verschiedenen Punkten. Zum einen ist eine Verbesserung der Aufrufzeiten zu erkennen, zusätzlich 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 6 Abfragen an die Datenbank gestellt werden, da die Einzelabfragen für die Adressen der
|
||||
Personen und der Koautoren komplett entfallen.
|
||||
|
||||
|
|
@ -663,8 +667,8 @@ Nach dem Anpassungen haben sich dann die Werte aus \autoref{tbl:measure-material
|
|||
\label{tbl:measure-materialized-view-ext}
|
||||
\end{table}
|
||||
|
||||
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
|
||||
Da bei der \textit{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 circa 1 ms für das reine Datenladen und 3 ms
|
||||
|
|
@ -762,8 +766,8 @@ Lösung auf eine kürzere Laufzeit und weniger Last am Server.
|
|||
\label{sec:performance-investigation-application:optimizing-query}
|
||||
|
||||
Für die Optimierung der Abfrage werden diese zuerst mit \textit{explain}, wie in \autoref{lst:explain-diagnostic}
|
||||
dargestellt, untersuchen. Für die einfachere Diagnose, wird der erstellte Plan Mithilfe von pev2
|
||||
\citep{GitHubda51:online} visualisiert.
|
||||
dargestellt, untersuchen. Für die einfachere Diagnose, wird der erstellte Plan mit Hilfe von
|
||||
\textit{Postgres Explain Visualizer 2} (\url{https://github.com/dalibo/pev2}) visualisiert.
|
||||
|
||||
\begin{lstlisting}[language=SQL,caption={Explain für Diagnose},label=lst:explain-diagnostic]
|
||||
explain (analyze, verbose, buffers, summary, format json)
|
||||
|
|
@ -845,6 +849,40 @@ vorhanden.
|
|||
\label{fig:explain-visualize-with}
|
||||
\end{figure}
|
||||
|
||||
Bei der Untersuchung der Abfrage zur Materialized View ist direkt herausgekommen, dass hier keine Optimierung mehr
|
||||
möglich ist, da durch die definierten Index bei den aktuell möglichen Sortierkriterien direkt ein \textit{Index Scan}
|
||||
verwendet wird. Damit ist der schnellstmögliche Zugriff gegeben.
|
||||
Bei der Untersuchung der Abfrage zur \textit{Materialized View} ist direkt herausgekommen, dass hier keine Optimierung
|
||||
mehr möglich ist, da durch die definierten Index bei den aktuell möglichen Sortierkriterien direkt ein
|
||||
\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]
|
||||
explain (analyze)
|
||||
select sd.id, documentid, datetype, startyear, startmonth, startday
|
||||
, startdatestatus , endyear, endmonth, endday, enddatestatus
|
||||
, author, coauthors, addressees, city, documentcategory
|
||||
, ispublishedindb, createdat, modifiedat, validuntil
|
||||
from searchdocument sd
|
||||
order by startyear desc, startmonth desc, startday desc
|
||||
limit 400;
|
||||
\end{lstlisting}
|
||||
|
||||
Der dazugehörige Abfrageplan ist in \autoref{lst:explain-search-document-output} zu sehen, hierbei ist die erste
|
||||
Ausgabe mit dem erstellten Index und vor der zweiten Ausgabe wurde der Index deaktiviert. Anhand der Ausgabe ist zu
|
||||
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 es möglich ist, direkt in den Index die Elemente in der richtigen Reihenfolge zu ermitteln.
|
||||
Somit ist durch den Index der schnellstmögliche Zugriff gegeben.
|
||||
|
||||
\begin{lstlisting}[basicstyle=\scriptsize,caption={aa},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
|
||||
Execution Time: 0.732 ms
|
||||
|
||||
Limit (cost=747.69..748.69 rows=400 width=948) (actual time=2.128..2.146 rows=400 loops=1)
|
||||
-> Sort (cost=747.69..760.90 rows=5285 width=948) (actual time=2.127..2.135 rows=400 loops=1)
|
||||
Sort Key: startyear DESC, startmonth DESC, startday DESC
|
||||
Sort Method: top-N heapsort Memory: 703kB
|
||||
-> Seq Scan on searchdocument sd (cost=0.00..492.85 rows=5285 width=948) (actual time=0.006..0.943 rows=5285 loops=1)
|
||||
Planning Time: 0.056 ms
|
||||
Execution Time: 2.164 ms
|
||||
\end{lstlisting}
|
||||
|
|
|
|||
|
|
@ -9,33 +9,31 @@ der Effektivität mit beachtet.
|
|||
|
||||
Es wurden die Konfigurationen der Caches von OpenJPA, JPA und EJB aktiviert und deren Auswirkung betrachtet. Bei den
|
||||
Caches, bei denen eine Größe angebbar ist, wurde zusätzlich mit der Anzahl variiert, um zu ermitteln in welchen Umfang
|
||||
sich diese auswirkt. Des Weiteren wird die Art der Programmierung für die Abfragen betrachtet, ob es signifikante
|
||||
Unterschiede in der Performance und der Abarbeitung ergibt. Als weitere Punkt werden die Abfragen an die Datenbank
|
||||
untersucht, um zu ermitteln ob diese durch Umstellung verbessert werden können. Als letzten werden die Materialisierten
|
||||
Sichten verwendet, um zu ermitteln, ob durch einen vorverdichteten und aufbereiteten Datenbestand die Abfragen
|
||||
beschleunigt werden können.
|
||||
|
||||
\mytodos{Zusätzlich beschreiben welche Möglichkeiten man genau genutzt hat und warum bzw. warum nicht}
|
||||
sich diese auswirkt. Des Weiteren wird die Art der Programmierung für die Abfragen betrachtet, ob signifikante
|
||||
Unterschiede in der Performance und der Abarbeitung erkennbar sind. Als weiteren Punkt werden die Abfragen an die
|
||||
Datenbank untersucht, um zu ermitteln ob diese durch Umstellung verbessert werden können. Abschließend werden die
|
||||
\textit{Materialized View} verwendet, um zu ermitteln, ob durch einen vorverdichteten und aufbereiteten Datenbestand
|
||||
die Abfragen beschleunigt werden können.
|
||||
|
||||
\section{Nutzerumfrage}
|
||||
\label{sec:evaluation:user-survey}
|
||||
|
||||
Zusätzlich war noch eine Befragung unter den Benutzer und den Entwicklern geplant. Da hierfür nur fünf Personen zur
|
||||
Verfügung stehen, ist dies nicht zielführend. Daher ist die sinnvolle Alternative ein rein technischer Ansatz, der
|
||||
gewählt wurde.
|
||||
Zusätzlich war noch eine Befragung unter den Benutzer und den Entwicklern geplant. Auf Grund dessen, dass nur fünf
|
||||
Personen zur Verfügung stehen ist dies nicht zielführend. Daher ist die einzig sinnvolle Alternative, welche gewählt
|
||||
wurde, ein rein technischer Ansatz.
|
||||
|
||||
\section{Statische Webseiten}
|
||||
\label{sec:evaluation:static-website}
|
||||
|
||||
Wenn man die Dokumentenliste als statische Webseiten ablegt, werden die Zugriffszeiten sehr kurz sein. Darüber hinaus
|
||||
funktionieren in statische Webseiten aber keine Suche oder eine Sortierung. Die Sortierung könnte durch das erstellen
|
||||
von statischen Seite aller Möglichkeiten der Sortierung emuliert werden, diese würde den notwendigen Speicherbedarf der
|
||||
Eine Umstellung der Dokumentenliste in statische Webseite, würde die Zugriffszeiten sehr verkürzen. Darüber hinaus
|
||||
funktionieren in statischen Webseiten aber keine Suchen oder eine Sortierungen. Die Sortierung könnte durch das Erstellen
|
||||
von statischen Seiten aller Möglichkeiten der Sortierung emuliert werden, diese würde den notwendigen Speicherbedarf der
|
||||
Webseite vervielfachen. Für die Suchanfragen ist dies nicht mehr möglich, da nicht alle Suchanfragen vorher definiert
|
||||
werden können.
|
||||
|
||||
Die Umstellung der Suche auf Client"=Basis wäre noch eine Möglichkeit, dafür benötigen die Clients entsprechend
|
||||
Leistung und es muss eine Referenzdatei erstellt werden, die alle Informationen über die Dokumente beinhaltet, nach der
|
||||
gesucht werden kann.
|
||||
Leistung und es muss eine Referenzdatei erstellt werden, die alle Informationen über die Dokumente beinhaltet, nach
|
||||
welcher gesucht werden kann.
|
||||
|
||||
Daher ist eine Umstellung auf statische Webseiten nicht sinnvoll.
|
||||
|
||||
|
|
@ -43,23 +41,20 @@ Daher ist eine Umstellung auf statische Webseiten nicht sinnvoll.
|
|||
\label{sec:evaluation:client-side-rendering}
|
||||
|
||||
Als weitere Möglichkeit könnte man die Webseite so umbauen, dass die Daten erst im Nachgang über eine AJAX-Anfrage
|
||||
ermittelt und die Sortierung und Aufteilung im Client durchgeführt wird. Hierbei wird aber je nach Datenmenge ein
|
||||
großer Speicher am Client benötigt und die Rechenleistung wird auf den Client verschoben.
|
||||
ermittelt und die Sortierung und Aufteilung im Client durchgeführt wird. Hierbei wird allerdings je nach Datenmenge ein
|
||||
großer Speicher am Client benötigt und der Großteil der benötigten Rechenleistung zu dem Client verschoben.
|
||||
|
||||
Dies wiederrum ist ein Vorteil für den Serverbetreiber, da durch die Verschiebung weniger Rechenleistung am Server
|
||||
benötigt wird. Gleichzeitig würde man damit wiederrum schwächere Clients, wie Smartphones, aussperren, da bei diesem
|
||||
benötigt wird. Gleichzeitig würde man wiederrum schwächere Clients, wie Smartphones, aussperren, da bei diesem
|
||||
die notwendige Rechenleistung fehlt, um die Webseite in annehmbarer Zeit darzustellen.
|
||||
|
||||
\section{Auswertung der Ergebnisse vor und nach der Optimierung}
|
||||
\label{sec:evaluation:result-optimization}
|
||||
|
||||
\subsection{Caching im OpenJPA}
|
||||
\label{sec:evaluation:result-optimization:caching-jpa}
|
||||
\section{Caching im OpenJPA}
|
||||
\label{sec:evaluation:caching-jpa}
|
||||
|
||||
Bei der Verwendung des OpenJPA"=Caches gibt es einige Verbesserungen in der Geschwindigkeit zu sehen. Die Höhe der
|
||||
Optimierungen hängt stark von der gewählten Cache"=Größe und der aufgerufenen Webseiten ab. Solange die Anfragen sich
|
||||
auf die gleichen Objekte beziehen und diese alle im Cache hinterlegt werden können, fällt die Optimierung entsprechend
|
||||
hoch aus. Sobald bei den Anfragen aber häufig die zu ermittelnden Objekt sich unterscheiden und alte Objekte wieder
|
||||
hoch aus. Sobald bei den Anfragen aber häufig die zu ermittelnden Objekte sich unterscheiden und alte Objekte wieder
|
||||
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
|
||||
|
|
@ -67,38 +62,37 @@ den Speicherbedarf noch weiter erhöht, da diese Objekte nicht in die Zählung d
|
|||
Was uns direkt zum größten Nachteil diese Caches kommen lässt, die notwendig Speichermenge die 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 entleeren wird. Gerade bei kleiner dimensionierten Servern stellt dies ein
|
||||
größeres Problem dar, da dann weniger Speicher für die anderen laufenden Programme, wie dem Datenbankmanagementsystem,
|
||||
größeres Problem dar, da nun weniger Speicher für die anderen laufenden Programme, wie dem Datenbankmanagementsystem,
|
||||
zur Verfügung steht.
|
||||
|
||||
Hierbei ist aber noch zu beachten, dass die Optimierung durch den Cache nicht die Laufzeit der Abfragen in der Datenbank
|
||||
enorm verringert hat, sondern die Laufzeit beim erstellen der Objekte im \textit{OpenJPA}"=Framework. Dies sieht man
|
||||
enorm verringert hat, sondern die Laufzeit beim Erstellen der Objekte im \textit{OpenJPA}"=Framework. Dies sieht man
|
||||
sehr gut schon bei der ersten Messung, wie in \autoref{tbl:measure-ojpa-active}. Hierbei werden die Laufzeit in der
|
||||
Datenbank im Schnitt um circa 5 ms reduziert, aber die komplette Webseite wird fast 100 ms schneller an den Client
|
||||
ausgeliefert. Dies ist nur dadurch erklärbar, dass das erstellen und mit den Datenwerte zu befüllen mehr Zeit kostet,
|
||||
Datenbank im Schnitt um circa 5 ms reduziert, allerdings wird die komplette Webseite fast 100 ms schneller an den Client
|
||||
ausgeliefert. Dies ist nur dadurch erklärbar, dass das Erstellen und mit den Datenwerte zu befüllen mehr Zeit kostet,
|
||||
als das Objekt aus dem Cache zu ermitteln und zurückzugeben.
|
||||
|
||||
Daher ist die Verwendung des OpenJPA"=Cache nur in Verbindung mit einem größer dimensionierten Server gut verwendbar,
|
||||
wenn der Großteil der Objekte im Cache gehalten werden kann. Bei Bedarf sollten die häufig frequentierten Objekte
|
||||
explizit im Cache aufgenommen und angepinnt werden.
|
||||
|
||||
\subsection{Cached Queries}
|
||||
\label{sec:evaluation:result-optimization:cached-queries}
|
||||
\section{Cached Queries}
|
||||
\label{sec:evaluation:cached-queries}
|
||||
|
||||
Die Optimierung über die gespeicherten Anfragen brachte keine Verbesserung hervor. Dies ist dadurch erklärbar, dass
|
||||
für die diese Art nur Anfragen verwendet werden, die keinerlei Bedingungen besitzen. Da in diesem Fall in der Tabelle
|
||||
auch noch nicht freigegebene und ungültige Datensätze gespeichert sind, müssen diese vor dem übertragen herausgefiltert
|
||||
für die diese Art nur Anfragen verwendet werden, die keinerlei Bedingungen besitzen. In diesem Fall sind in der Tabelle
|
||||
noch nicht freigegebene und ungültige Datensätze gespeichert, daher müssen diese vor dem Übertragen herausgefiltert
|
||||
werden. Dies ist der Grund warum diese Anfragen in diesem Cache nicht gespeichert werden.
|
||||
|
||||
Dadurch ist dieser Cache für eine Performance"=Verbesserung in unseren Fall nicht verwendbar.
|
||||
Dadurch ist dieser Cache für eine Performance"=Verbesserung in dem Fall der Dokumentenliste nicht anwendbar.
|
||||
|
||||
\subsection{Caching mit Ehcache}
|
||||
\label{sec:evaluation:result-optimization:ehcache}
|
||||
\section{Caching mit Ehcache}
|
||||
\label{sec:evaluation:ehcache}
|
||||
|
||||
\mytodos{fehlt noch}
|
||||
Mit dem Ehcache konnte eine Verbesserung in der Performance erzielt werden. Im Vergleich zum Cache von OpenJPA sind
|
||||
die Verbesserung sehr ähnlich. Die Standardwerte dieses Caches sind gut vordefiniert, es wird für den aktuellen Fall
|
||||
keine Anpassung benötigt um eine gute Performance zu bekommen. Hierbei ist natürlich das gleiche Problem wie in anderen
|
||||
Caches, dass beim erreichen der Grenzen, alte Objekte entfernt werden müssen.
|
||||
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.
|
||||
Im Falle des Ehcache ist die interne Verwaltung auf mehrere Caches aufgebaut, dies ist daran zu sehen, dass in der
|
||||
|
|
@ -106,91 +100,91 @@ Standardkonfiguration jede Klasse ihren eigenen Cache besitzt. Diese können ein
|
|||
werden, um diese genau auf die jeweiligen Bedürfnisse der Objekte anzupassen.
|
||||
|
||||
Im Falle der Verwendung des Caches, ist auch hier gut zu sehen, dass der Speicheranstieg bei der Verwendung des Caches
|
||||
sehr gering ist, was den Schluss zu lässt, dass der Cache nur zu einem kleinen
|
||||
sehr gering ist, was den Schluss zulässt, dass der Cache nur zu einem kleinen \mytodos{hier fehlt was}
|
||||
|
||||
Durch die effizienter Verwendung des Speichers, ist der Ehcache die bessere Alternative zum OpenJPA"=Cache. Dieser ist
|
||||
auch schon für kleinere Serverkonfigurationen gut verwendbar. Hierbei ist nur abzuwägen, mit welcher Größe der Cache
|
||||
bereitgestellt werden kann, was direkt am verfügbaren Arbeitsspeicher abhängt.
|
||||
|
||||
\subsection{Caching in EJB}
|
||||
\label{sec:evaluation:result-optimization:ejb}
|
||||
\section{Caching in EJB}
|
||||
\label{sec:evaluation:ejb}
|
||||
|
||||
Bei der Erweiterung des EJB konnte keine Verbesserung in der Performance festgestellt werden. Dies liegt daran, dass
|
||||
im EJB"=Cache die Provider beinhaltet, aber keine Daten"=Objekte. Dadurch kann der Cache das ermitteln der Objekte
|
||||
Bei der Erweiterung des EJB konnte keine Verbesserung in der Performance festgestellt werden. Der Grund hierfür ist, dass
|
||||
im EJB"=Cache die Provider beinhaltet, aber keine Daten"=Objekte. Dadurch kann der Cache das Ermitteln der Objekte
|
||||
nicht optimieren.
|
||||
|
||||
Aufgrund dessen ist der EJB"=Cache nicht für eine Performance"=Verbesserung nutzbar.
|
||||
Auf Grund dessen ist der EJB"=Cache nicht für eine Performance"=Verbesserung nutzbar.
|
||||
|
||||
\subsection{Abfragen mit JPQL und Criteria API}
|
||||
\label{sec:evaluation:result-optimization:jpal-capi}
|
||||
\section{Abfragen mit JPQL und Criteria API}
|
||||
\label{sec:evaluation:jpal-capi}
|
||||
|
||||
Bei dem Vergleich zwischen den 2 Abfragemöglichkeiten der \ac{JPQL} und der Criteria API konnte in der Art der Abfragen
|
||||
kein Unterschied dargestellt werden. Die Abfragen der beiden Systeme sind auf der Datenbankseite komplett identisch.
|
||||
Auch in der Übertragung der Daten aus der Datenbank in die Java"=Objekte konnte keine Unterschied in der Art und
|
||||
Geschwindigkeit festgestellt werden.
|
||||
Bei dem Vergleich zwischen den zwei Abfragemöglichkeiten der \ac{JPQL} und der Criteria API konnte in der Art der
|
||||
Abfragen kein Unterschied festgestellt werden. Die Abfragen der beiden Systeme sind auf Datenbankseite komplett
|
||||
identisch. Auch in der Übertragung der Daten aus der Datenbank in die Java"=Objekte konnte keine Unterschied in der
|
||||
Art und Geschwindigkeit festgestellt werden.
|
||||
|
||||
Ebenfalls sind die Möglichkeiten über der Optimierung über Hints identisch. In beiden Fällen, haben die meisten Hints
|
||||
keine nennenswerten Einfluss auf die Laufzeit der Abfragen und Übertragung in die Java"=Objekte. Das sinnvolle setzen
|
||||
keine 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.
|
||||
|
||||
Anders ist dies mit dem Einstellungen für EagerFetchMode, welche definiert wie die Daten für abhängige Klasse ermittelt
|
||||
werden. Bei Umstellung auf \textit{parallel} konnte für die Ermittlung der Dokumente einiges an Performance gewonnen
|
||||
Anders verhält sich dies mit den Einstellungen für EagerFetchMode, welche definiert wie die Daten für abhängige Klasse
|
||||
ermittelt werden. Bei Umstellung auf \textit{parallel} konnte für die Ermittlung der Dokumente einiges an Performance gewonnen
|
||||
werden. Das liegt daran, dass nun für die abhängigen Objekte, wie den Koautoren, nicht pro Dokument eine Anfrage an die
|
||||
Datenbank gestellt wird, sondern es werden alle Koautoren für die ermittelten Dokumente auf einmal ermittelt. Die
|
||||
Zuordnung der Koautoren zu dem Dokument wird dann nun im Framework und nicht mehr durch die Datenbank durchgeführt.
|
||||
Diese Abarbeitung spart viele einzelne Abfragen und somit auch den entsprechend Overhead im Framework.
|
||||
Diese Abarbeitung reduziert viele einzelne Abfragen und somit auch den entsprechend Overhead im Framework.
|
||||
|
||||
Aufgrund dessen ist die Entscheidung der Technik für die Performance irrelevant und es kann das genutzt werden, was für
|
||||
jeweiligen Einsatzzweck besser beziehungsweise einfacher zu programmieren ist. Das setzen der richtigen Hints wiederrum
|
||||
ist in beiden Fällen äußerst wichtig. Explizit der EagerFetchMode muss vorher darüber nachgedacht werden, wie viele
|
||||
Auf Grund dessen ist die Entscheidung der Technik für die Performance irrelevant und es kann das genutzt werden, was für
|
||||
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
|
||||
ausgegangen werden kann. Gerade bei ein größeren Anzahl lohnt es sich den Hint auf \textit{parallel} zu setzen.
|
||||
Gleiches gilt den Hint SubclassFetchMode, dieser steuert dimensionierten Abfragen im falle von abgeleitet Klassen.
|
||||
Gleiches gilt dem Hint SubclassFetchMode, dieser steuert dimensionierte Abfragen im Falle von abgeleiteten Klassen.
|
||||
|
||||
\subsection{Materialized View}
|
||||
\label{sec:evaluation:result-optimization:materialized-view}
|
||||
\section{Materialized View}
|
||||
\label{sec:evaluation:materialized-view}
|
||||
|
||||
Die Idee der Materialisierten Sichten ist simple aber sehr effizient, gerade für einen Datenbestand der häufig gelesen
|
||||
Die Idee der \textit{Materialized View} ist simple aber sehr effizient, gerade für einen Datenbestand welcher häufig gelesen
|
||||
und selten verändert wird. Hierbei werden komplexe Abfragen einmalig ausgeführt und das Ergebnis intern
|
||||
zwischengespeichert. Für alle weiteren Aufrufe, werden die Daten nun aus der Zwischenspeicher gelesen und dem Aufrufer
|
||||
zurückgegeben. Bei einer Änderung an den Quelldaten muss die Sicht aktualisiert werden, was der größte Nachteil der
|
||||
Materialisierten Sichten ist. Dieser Nachteil kommt in einer Briefedition nicht zum tragen, da in dieser nach dem die
|
||||
Briefe einmalig eingepflegt wurde, noch selten Änderungen erfahren. Die Recherche über den Datenbestand die größte Zeit
|
||||
zurückgegeben. Der größte Nachteil der \textit{Materialized View} ist, das bei einer Änderung an den Quelldaten die
|
||||
Sicht aktualisiert werden muss. Dieser Nachteil kommt in einer Briefedition nicht zum tragen, da in dieser nach dem die
|
||||
Briefe einmalig eingepflegt wurden, noch selten Änderungen erfahren. Die Recherche über den Datenbestand die größte Zeit
|
||||
gewidmet wird.
|
||||
|
||||
Ein weiterer Nachteil der Materialisierten Sichten ist die doppelte Speicherung der Daten, da die Daten für die Sicht
|
||||
wie bei einer Tabelle auf der Festplatte gespeichert sind. Dieser Nachteil ist in der DOkumentliste vernachlässigbar,
|
||||
Ein weiterer Nachteil der \textit{Materialized View} ist die doppelte Speicherung der Daten, da die Daten für die Sicht
|
||||
wie bei einer Tabelle auf der Festplatte gespeichert sind. Dieser Nachteil ist in der Dokumentliste vernachlässigbar,
|
||||
da sich die Daten auf die Meta"=Daten der Dokumente, wie Namen, Datum und Autoren beschränkt. Der größte Datenbestand,
|
||||
die Faksimile, sind nicht in dieser Sicht enthalten und werden erst beim Anzeigen einer Kommunikation ermittelt.
|
||||
Zusätzlich ist zu beachten, dass bei der Verwendung eines Caches die Daten ebenfalls doppelt gehalten werden und in
|
||||
den meisten Fällen im Arbeitsspeicher gehalten werden.
|
||||
|
||||
Eine zusätzliche Optimierung die durch die Materialisierte Sicht entstanden ist, ist die direkte integration der
|
||||
Autoren, der Koautoren und der Adressen im \textit{Json}"=Format. Durch diesen aus dem Wedekind-Projekt übernommene Idee
|
||||
Eine weitere Optimierung, welche durch die \textit{Materialized View} entstanden ist, ist die direkte integration der
|
||||
Autoren, der Koautoren und der Adressen im \textit{Json}"=Format. Durch diese aus dem Wedekind-Projekt übernommene Idee
|
||||
konnten schon viele zusätzliche Abfragen eingespart werden, da diese nicht mehr durch OpenJPA nach der Hauptabfragen
|
||||
für jede Datenzeile einzeln durchgeführt wird.
|
||||
|
||||
Zusätzlich konnte dies nochmal beschleunigt werden, in dem das parsen der \textit{Json}"=Daten vom Server auf den Client
|
||||
verlagert wurde. Hiermit konnte zum einen Last vom Server genommen werden und die gesamte Ausführungszeit nochmals
|
||||
optimieren. Die Wandlung der Daten in \textit{HTML}"=Objekte ist eine Kernkompetenz von JavaScript und damit auch auf
|
||||
schwächeren Clients in kurzer zeit zu erledigen.
|
||||
optimieren. Die Wandlung der Daten in \textit{HTML}"=Objekte ist eine Kernkompetenz von JavaScript und damit auch bei
|
||||
schwächeren Clients in kurzer Zeit durchzuführen. \mytodos{durchführbar?}
|
||||
|
||||
Zusammenfassend ist zu sagen, dass die Materialisierten Sichten eine gute Wahl sind, um die Listendarstellungen
|
||||
Zusammenfassend ist zu sagen, dass die \textit{Materialized View} eine gute Wahl sind, um die Listendarstellungen
|
||||
zu optimieren. Mit dieser Technik können zum einen die Abfragezeiten optimiert werden, wodurch gleichzeit die
|
||||
Ressourcennutzung verringert wird. Zum anderen wird die Ressourcennutzung des Servers noch weiter reduziert, wenn die
|
||||
\textit{Json}"=Verarbeitung an den Client ausgelagert wird.
|
||||
Durch die doppelte Datenhalten muss bei jeder Abfrage geprüft werden, ob der Nutzung der Materialisierte Sicht sinnvoll
|
||||
Durch die doppelte Datenhalten muss bei jeder Abfrage geprüft werden, ob der Nutzung der \textit{Materialized View} sinnvoll
|
||||
ist oder direkt auf denormalisierte Daten umgestellt werden sollte, weil der zusätzliche benötigte Speicher größer als
|
||||
die Quelle ist.
|
||||
Im Gegensatz zu einer reinen Cache"=Lösung die die gleiche Optimierung besitzt, ist diese vorzuziehen, da in den
|
||||
meisten Fällen der Festplattenspeicher kostengünstiger als der Arbeitsspeicher ist. Zusätzlich ist der Cache begrenzt
|
||||
und wirft alte Objekte aus dem Cache, wenn dieser voll ist und dadurch wird ein Zugriff auf so ein Objekt wieder
|
||||
langsamer. Somit ist die Optimierung über die Materialisierten Sichten auf langezeit gesehen kostengünstiger und
|
||||
langsamer. Somit ist die Optimierung über die \textit{Materialized View} auf langezeit gesehen kostengünstiger und
|
||||
stabiler.
|
||||
|
||||
\subsection{Optimierung der Abfrage}
|
||||
\label{sec:evaluation:result-optimization:optimize-query}
|
||||
\section{Optimierung der Abfrage}
|
||||
\label{sec:evaluation:optimize-query}
|
||||
|
||||
Die Abfragen die durch die OpenJPA an die Datenbank abgesetzt werden, sind meist durch ihre Einfachheit gut optimiert.
|
||||
Nur durch Sortierung oder Bedingungen können die Abfragen langsam werden. Diese können durch entsprechende Indexe
|
||||
|
|
@ -200,11 +194,18 @@ werden. Die Hauptabfrage der Dokumentenliste ist eine mit mehreren Joins, und di
|
|||
Der Abfrageplan der Hauptabfrage wurde visuell untersucht und zeigt, dass das Hauptproblem die nicht eingeschränkte
|
||||
Datenmenge der Haupttabelle \textit{document} ist. Dadurch werden zum einen die anderen Tabellen komplett dazu geladen
|
||||
und es werden trotz direkter Primary Key Bedingungen keine Zugriffe über die Index durchgeführt. Für den PostgreSQL
|
||||
ist es laut Berechnung kostengünstiger mit einem \textit{Seq Scan}, was einem Tabellenscan entspricht, zu arbeiten.
|
||||
ist es laut Berechnung kostengünstiger mit einem \textit{Seq Scan}, was einem kompletten Durchlaufen der Tabelle
|
||||
entspricht, zu arbeiten.
|
||||
|
||||
Um dies zu optimieren, wurde über eine \textit{Common Table Expression} zuerst die eingeschränkten Datenzeilen
|
||||
ermittelt, dieser mit der Haupttabelle verknüpft und nun die anderen Tabellen dazugenommen. Hierdurch konnten die
|
||||
Zeilenanzahl enorm verringert werden, wodurch einige der Verknüpfungen auf Indexzugriffe umgestellt wurden.
|
||||
Durch die Umstellung konnte die Abfragezeit mehr als das dreifache reduziert wurde.
|
||||
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 wurde.
|
||||
|
||||
\mytodos{hier weiter...}
|
||||
Mit dieser Art der Umstellung können Abfragen optimiert werden, die fürs 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
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -5,5 +5,45 @@
|
|||
|
||||
\mytodos{hier eine kurze Zusammenfassung über 2-3 Seiten}
|
||||
|
||||
\iffalse
|
||||
% umstellung auf matview sinnvoll bei verwendung von joins
|
||||
% bei joins von 1:n ist die Wandlung über json sinnvoll, aber parsen erst am client
|
||||
|
||||
!!! Hier nochmal die Nutzerumfrage mit einbringen
|
||||
|
||||
- Einführung in die Ergebnisse
|
||||
- Darstellung der Kernergebnisse
|
||||
- Analyse und Interpretation
|
||||
- Einordnung in den Forschungskontext
|
||||
- Zusammenfassung und Übergang zur Diskussion
|
||||
|
||||
Du beginnst mit einer präzisen Beschreibung deiner Untersuchung, um ein klares Verständnis der Grundlagen zu schaffen,
|
||||
und hebst spezifische Daten sowie Analysemethoden hervor (1).
|
||||
|
||||
Anschließend präsentierst du die Kernergebnisse deiner Forschung klar und strukturiert, fokussierst dabei auf
|
||||
relevante Entdeckungen, die direkt zur Beantwortung deiner Forschungsfrage beitragen (2).
|
||||
|
||||
Eine tiefgehende Analyse folgt, in der du die Daten nicht nur beschreibst, sondern auch im Kontext der theoretischen
|
||||
Grundlagen interpretierst und untersuchst, wie sie deine Hypothesen unterstützen oder herausfordern (3).
|
||||
|
||||
Die Ergebnisse setzt du dann in den breiteren akademischen und praktischen Forschungskontext und diskutierst ihren
|
||||
Beitrag zu bestehenden Theorien sowie die sich eröffnenden neuen Perspektiven (4).
|
||||
|
||||
Abschließend fasst du die wichtigsten Erkenntnisse zusammen und schaffst einen nahtlosen Übergang zur Diskussion,
|
||||
indem du betonst, wie deine Ergebnisse die ursprünglichen Fragestellungen untersucht haben und welche Folgen sich für
|
||||
weiterführende Forschungen ergeben könnten (5).
|
||||
\fi
|
||||
|
||||
Das Ziel dieser Bachelorarbeit war es, durch die Untersuchung der Schichten am Beispiel des Wedekind"=Projektes
|
||||
Optimierungsmöglichkeiten zu finden. Für die Untersuchung wurde sich auf die Dokumentenliste beschränkt und anhand
|
||||
dieser die Optimierungen implementiert, untersucht und jeweils mit dem Ausgangspunkt verglichen.
|
||||
Hierzu wurde der Aufbau der Software in seine unterschiedlichen Schichten zerlegt und diese einzeln Untersucht.
|
||||
Für jede Schicht wurde
|
||||
Bei den Schichten
|
||||
wurde, zu diesen zählen
|
||||
die Enterprise Java Beans, die Java Persistance API, die OpenJPA,
|
||||
|
||||
|
||||
Für dieses Ziel wurde sich auf die Dokumentenliste beschränkt und diese jeweils
|
||||
für die unterschiedllichen Optimierungen angepasst.
|
||||
Es wurde
|
||||
|
|
@ -20,3 +20,13 @@
|
|||
\end{center}
|
||||
|
||||
\end{otherlanguage}
|
||||
|
||||
% Aufbau, und sollte max 1 A4 Seite sein!!
|
||||
% - Einstieg in das Thema
|
||||
% - Problemlage, Fragestellung, Methodik
|
||||
% - Wichtigste Ergebnisse
|
||||
% - Einordnung in Forschungsrahmen
|
||||
% - Ausblick und Bedeutung
|
||||
|
||||
% beginnen mit:
|
||||
% Das Ziel dieser Bachelorarbeit ist ...
|
||||
|
|
|
|||
BIN
thesis.pdf
BIN
thesis.pdf
Binary file not shown.
Loading…
Reference in a new issue