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

Daily CheckIn

Browse source
This commit is contained in:
marcodn 2024-09-05 00:02:53 +02:00
parent 40014ecaae
commit f8a8a0c869
3 changed files with 57 additions and 45 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

101
chapters/thesis/chapter05.tex
View file

@ -22,11 +22,21 @@ Konfigurationsänderung im Payara-Server von \texttt{-Xmx512m} auf \texttt{-Xmx4
ca. 60 Aufrufe des Scripts benötigt, damit der Server nicht mehr reagiert. Hierbei wird aber kein OutOfMemoryError
in der Log-Datei protokolliert und der Server verwendet nun ca. 4700 MB RSS. Bei allen Tests war noch mehr als die
Hälfte des verfügbaren Arbeitsspeichers des Computers ungenutzt.
\mytodos{-Xmx definiert die Größe des Verwendbaren Heapspeichers}
Mit der Konfiguration \texttt{-Xmx} wird der maximal verwendbare Heap"=Speicher in der \ac{JVM} definiert.
Dies zeigt direkt, dass es ein Problem in der Freigabe der Objekte gibt, da dass erhöhen des verwendbaren Arbeitsspeicher
das Problem nicht löst, sondern nur verschiebt.
Für alle nachfolgenden Messungen wird das Skript \ref{ap:calling_script} verwendet, welches die einzelnen Aufrufe
steuert. Die Ergebnisse werden in eine Tabelle überführt, wie in der Tabelle \ref{tbl:measure-without-cache}.
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 SQL Abfragen
ermitteln, auch hier gilt, dass weniger Aufrufe besser sind. Als letztes wird noch der verwendete Arbeitsspeicher
vom \textit{Glassfish}"=Server vor und nach dem Aufruf ermittelt und die Differenz gebildet, hierbei sollte im besten
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.
Als Grundlage für die Vergleiche wurden eine Messung durchgeführt, bei der alle Caches deaktiviert wurden und keine
Änderung am Code vorgenommen wurde. Das Ergebnis dieser Messung ist in \ref{tbl:measure-without-cache} zu finden. Diese
zeigen auch direkt ein erwartetes Ergebnis, dass der erste Aufruf bedeutend länger dauert als die Nachfolgenden.
@ -34,8 +44,6 @@ Ebenfalls sieht man eindeutig, dass die Anzahl der Anfragen nach dem ersten Aufr
Der Speicherbedarf steigt auch relative gleichmässig, was nicht recht ins Bild passt, da hier keine Objekte im Cache
gehalten werden sollten.
\mytodos{hier noch beschreiben, wie die Werte zu interpretieren sind, und hervorheben, dass dies nun für alle Tabellen so gilt!}
\mytodos{hier noch text einfügen, der erklärt wie die Spalten zu werten sind, also Aufrufzeit ist kürzer gleich besser}
\mytodos{Diese Tabelle vielleicht auch einfach komplett streichen, da der Datenbestand anders ist, und das wichtigste
die Zeit der SQL-Abfragen nicht sichtbar ist}
@ -96,8 +104,6 @@ der Anzahl aller vorhandenen Dokumente.
\label{tbl:measure-without-cache-docker}
\end{table}
\mytodos{die Reihenfolge der Sektion dem Schichtmodel anpassen}
\section{Umgestalten der Datenbanktabellen}
\label{sec:performance-investigation-application:new-table}
@ -179,7 +185,9 @@ beschleunigt werden konnte.
\mytodos{Untersuchung mit deaktivieren SoftReference fehlt noch}
\mytodos{kurzes Fazit fehlt noch, anzahl der Queries für unterabfragen gehen auf 0 bzw. bleiben bei 400!}
Die Vergleich zeigt, dass der Cache eine gute Optimierung bringt, aber dies nur dann gut funktioniert, wenn immer
wieder die gleichen Objekte ermittelt werden. Sobald die Anfragen im Wechsel gerufen werden oder einfach nur der Menge
der Objekte den Cache übersteigt, fällt die Verbesserung gering aus.
\section{cached queries}
\label{sec:performance-investigation-application:cached-query}
@ -213,43 +221,42 @@ abfragt.
\mytodos{muss noch umgebaut werden, falsche Konfiguration erwischt}
%Die Cache-Einstellungen von \ac{JPA} werden über mehrere Einstellungen konfiguriert. Anhand von
%\texttt{eclipselink.query-results-cache} wird definiert, dass die Ergebnisse von benannten Abfragen im Cache
%gespeichert werden. Für den Zugriff in den Cache, wird neben den Namen noch die übergebenen Parameter
%berücksichtigt.
%% https://eclipse.dev/eclipselink/documentation/2.5/concepts/cache008.htm
Die Cache-Einstellungen von \ac{JPA} werden über mehrere Einstellungen konfiguriert. Anhand von
\texttt{eclipselink.query-results-cache} wird definiert, dass die Ergebnisse von benannten Abfragen im Cache
gespeichert werden. Für den Zugriff in den Cache, wird neben den Namen noch die übergebenen Parameter
berücksichtigt.
% https://eclipse.dev/eclipselink/documentation/2.5/concepts/cache008.htm
%Der geteilte Cache, der für die Dauer der persistenten Einheit (EntityManagerFactory oder der Server) vorhanden ist,
%kann über \texttt{eclipselink.cache.shared.default} gesteuert werden. Dieser kann nur aktiviert oder deaktiviert werden.
%% https://wiki.eclipse.org/EclipseLink/Examples/JPA/Caching
Der geteilte Cache, der für die Dauer der persistenten Einheit (EntityManagerFactory oder der Server) vorhanden ist,
kann über \texttt{eclipselink.cache.shared.default} gesteuert werden. Dieser kann nur aktiviert oder deaktiviert werden.
% https://wiki.eclipse.org/EclipseLink/Examples/JPA/Caching
%Mit \texttt{eclipselink.cache.size.default} wird die initiale Größe des Caches definiert, hierbei ist der Standardwert
%100. Die Objekt werden nicht direkt aus dem Cache entfernt, sondern erst nachdem der \ac{GC} diese freigeben hat.
%Zusätzlich wird über \texttt{eclipselink.cache.type.default} die Art des Caching gesteuert. Die Einstellung mit dem
%höchsten Speicherbedarf ist \textit{FULL}, bei dem alle Objekte im Cache bleiben, außer sie werden explizit gelöscht.
%Die Einstellung \textit{SOFT} und \textit{WEAK} sind sehr ähnlich, der unterschied ist die Referenzierung auf die
%Entität. Bei \textit{WEAK} bleiben die Objekte nur solange erhalten, wie die Anwendung selbst eine Referenz auf die
%Objekte fest hält. Im Gegensatz dazu bleibt bei \textit{SOFT} die Referenz so lange bestehen, bis der \ac{GC} wegen
%zu wenig Speicher Objekte aus dem Cache entfernt.
%% https://eclipse.dev/eclipselink/documentation/2.5/concepts/cache002.htm
Mit \texttt{eclipselink.cache.size.default} wird die initiale Größe des Caches definiert, hierbei ist der Standardwert
100. Die Objekt werden nicht direkt aus dem Cache entfernt, sondern erst nachdem der \ac{GC} diese freigeben hat.
Zusätzlich wird über \texttt{eclipselink.cache.type.default} die Art des Caching gesteuert. Die Einstellung mit dem
höchsten Speicherbedarf ist \textit{FULL}, bei dem alle Objekte im Cache bleiben, außer sie werden explizit gelöscht.
Die Einstellung \textit{SOFT} und \textit{WEAK} sind sehr ähnlich, der unterschied ist die Referenzierung auf die
Entität. Bei \textit{WEAK} bleiben die Objekte nur solange erhalten, wie die Anwendung selbst eine Referenz auf die
Objekte fest hält. Im Gegensatz dazu bleibt bei \textit{SOFT} die Referenz so lange bestehen, bis der \ac{GC} wegen
zu wenig Speicher Objekte aus dem Cache entfernt.
% https://eclipse.dev/eclipselink/documentation/2.5/concepts/cache002.htm
%Um den Cache zu deaktivieren wurden beiden Einstellungen auf \textit{false} gestellt, die Größe auf 0 und der Cache-Typ
%auf \textit{NONE}. Hierbei lag die maximale gemessene Laufzeit des ersten Aufrufs bei ca. 1300 ms und es wurden 12219
%Abfragen an die Datenbank gestellt. Bei den nachfolgenden Aufrufe lag die Aufrufzeit im Durchschnitt bei 350 ms und
%12080 Abfragen.
Um den Cache zu deaktivieren wurden beiden Einstellungen auf \textit{false} gestellt, die Größe auf 0 und der Cache-Typ
auf \textit{NONE}. Hierbei lag die maximale gemessene Laufzeit des ersten Aufrufs bei ca. 1300 ms und es wurden 12219
Abfragen an die Datenbank gestellt. Bei den nachfolgenden Aufrufe lag die Aufrufzeit im Durchschnitt bei 350 ms und
12080 Abfragen.
%Um den Cache wieder zu aktivieren wurden die Einstellungen auf \textit{true} gestellt, die Größe auf den Standardwert
%von 100 und der Cache-Type auf \textit{SOFT} gestellt. Hierbei wurde eine maximale Laufzeit beim ersten Aufruf ebenfalls
%von 1300 ms gemessen und es wurden 12218 Abfragen abgesetzt. Bei den nachfolgenden Aufrufen lag die Aufrufzeit im
%Durchschnitt bei 340 ms.
Um den Cache wieder zu aktivieren wurden die Einstellungen auf \textit{true} gestellt, die Größe auf den Standardwert
von 100 und der Cache-Type auf \textit{SOFT} gestellt. Hierbei wurde eine maximale Laufzeit beim ersten Aufruf ebenfalls
von 1300 ms gemessen und es wurden 12218 Abfragen abgesetzt. Bei den nachfolgenden Aufrufen lag die Aufrufzeit im
Durchschnitt bei 340 ms.
%Bei WEAK hat sich die Speichernutzung nur um 5MB gesteigert
Bei WEAK hat sich die Speichernutzung nur um 5MB gesteigert
%\mytodos{in einer Tabelle oder Graphen darstellen?}
\mytodos{in einer Tabelle oder Graphen darstellen?}
Wie man an den Daten erkennen kann, wird der Cache vom \ac{JPA} für diese Abfrage nicht verwendet, sonst müssten die
Anzahl der Abfragen an die Datenbank drastisch reduziert werden. Selbst die Laufzeit ändert sich nur marginal.
%Wie man an den Daten erkennen kann, wird der Cache vom \ac{JPA} für diese Abfrage nicht verwendet, sonst müssten die
%Anzahl der Abfragen an die Datenbank drastisch reduziert werden. Selbst die Laufzeit ändert sich nur marginal.
\section{Caching in \ac{EJB}}
\label{sec:performance-investigation-application:caching-ejb}
@ -538,12 +545,13 @@ Nach dem Anpassungen haben sich dann die Werte aus \ref{tbl:measure-materialized
\section{Java Server Faces}
\label{sec:performance-investigation-application:java-server-faces}
\mytodos{Zeitmessungen innerhalb der Anwendung über einen Flamegraphs darstellten https://www.brendangregg.com/flamegraphs.html}
\mytodos{Diese Zeitmessung vielleicht noch ins Obere Kapitel ala Ausgangspunkt verschieben}
%\mytodos{Zeitmessungen innerhalb der Anwendung über einen Flamegraphs darstellten https://www.brendangregg.com/flamegraphs.html}
%\mytodos{Diese Zeitmessung vielleicht noch ins Obere Kapitel ala Ausgangspunkt verschieben}
Wie in \ref{sec:performance-checking:performance-measure} beschrieben wurde, die Protokollierung für das erstellen einer
Webseite aktiviert. Bei komplett deaktivierten Cache sieht man, dass bei der Dokumentenliste der größte Zeitfaktor beim
Render der Sicht auftritt. Wenn man nun noch die Abfrage auf die Materialized-View umstellt, ist es noch auffälliger.
Wie in \ref{sec:performance-checking:performance-measure} beschrieben wurde, ist die Protokollierung für das erstellen
einer Webseite aktiviert. Bei komplett deaktivierten Cache sieht man, dass bei der Dokumentenliste der größte Zeitfaktor
beim Render der Sicht auftritt. Wenn man nun noch die Abfrage auf die Materialized-View umstellt, ist es noch
auffälliger.
\begin{table}[h!]
\centering
@ -576,7 +584,10 @@ Daher ist eine Umstellung auf statische Webseiten nicht sinnvoll.
\section{Client basierte Webseiten}
\label{sec:performance-investigation-application:client-side-rendering}
\mytodos{Beschreiben, dass alles auf dem client geschickt wird, und dort alles gerendert und sortiert wird,
damit aber schwächere Clients ausgeschlossen werden!
Hätte aber Vorteil für die Kosten des Servers, da dieser schwächer ausgelegt werden könnte und damit Geld einzusparen
wäre. !!!! Der Punkt könnte auch unter QueryCache gelagert werden !!!!}
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.
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
die notwendige Rechenleistung fehlt, um die Webseite in annehmbarer Zeit darzustellen.

1
frontbackmatter/thesis/Acronyms.tex
View file

@ -29,6 +29,7 @@
\acro{UML}{Unified Modeling Language}
\acro{GB}{Gigabyte}
\acro{SQL}{Structured Query Language}
\acro{JVM}{Java Virtual Machine}
\end{acronym}
\cleardoublepage

BIN
thesis.pdf
View file

Binary file not shown.