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

Dialy CheckIn

Browse source
This commit is contained in:
marcodn 2024-07-23 00:10:31 +02:00
parent a63f4414dd
commit 418b925b9f
3 changed files with 133 additions and 22 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

151
chapters/thesis/chapter04.tex
View file

@ -22,6 +22,7 @@ prüfen, die den Cache von OpenJPE auswerten}
\label{sec:performance-checking:performance-measure}
\mytodos{Einbau der Messungen direkt in die Webseite bzw. in ein Log}
\mytodos{Einstellung am postgresql um die queries mit zu loggen}
\section{Untersuchung der Anwendung}
\label{sec:performance-checking:investigation-application}
@ -29,19 +30,30 @@ prüfen, die den Cache von OpenJPE auswerten}
Nun werden die unterschiedlichen Schichten betrachtet und möglichen Performance-Verbesserungen untersucht und deren
Vor"= und Nachteile herausgearbeitet.
\mytodos{Bei deaktivierten Daten und Query-Cache hat der 3te Aufruf im Durchschnitt schon doppelt so lange gedauert wie
die 2 vorherigen und beim 4ten Aufruf ist der Payara-Server mit einer OutOfMemoryError-Exception im Java-Heapspeicher
ausgestiegen und musste per Kill-Befehl abgeschossen werden.
Angeblich liegt es am der Speicher-Option, in der domain1/config/dommain.xml die Einstellung <jvm-options>-Xmx512m</jvm-options>
gesucht und den Inhalt durch -Xmx4096m ersetzt.
Nach dem ändern der Konfiguration ist der absturz auch nach dem 30 Aufruf des Skriptes nicht reproduzierbar gewesen.
Nach dem zurückstellen auf 512 konnte man den Absturz nach relativ kurze Zeit erneute erzwingen (6ter Aufruf). Der
Arbeitspeicher-Verbraucht der Anwendung lag aber bei ca. 1500MB PSS}
Für die Tests wird ein aktuelles Manjaro-System mit frisch installierten Payara als Serverhost und der IntelliJ IDEA
als Entwicklungsumgebung verwendet. Der Computer ist mit einer Intel CPU i7-12700K, 32 GB Arbeitsspeicher und einer SSD
als Systemfestplatte ausgestattet.
Unterschied RSS und PSS erklären? PSS: non-swapped physical memory + anteiliger shared memory, RSS: non-swapped physical memory + shared memory, siehe man ps: https://man7.org/linux/man-pages/man1/ps.1.html
Zur ersten Untersuchung und der Bestimmung der Basis-Linie, wurde das Script ohne eine Änderung an dem Code und der
Konfiguration mehrfach aufgerufen. Hierbei hat sich gezeigt, dass der erste Aufruf nach dem Deployment ca. 1500 ms
gedauert hat. Die weiteren Aufrufe dauert dann im Durchschnitt bei 600 ms. Beim achten Aufruf des Scripts hat der
Server nicht mehr reagiert und im Log ist ein OutOfMemoryError protokolliert worden.
Bei 10 Aufrufen waren es ca. 50 MB mehr und bei 20 Aufrufen waren es ca. 100 MB mehr Arbeitspeichernutzung.
Nach umstellung auf 4096 ist der Server nach bei ca. 4700 MB RSS ausgestiegen. Aber ohne OutOfMemoryError und der Arbeitspeicher im ganzen war zur Hälfte benutzt.
Nach einem Neustart des Servers, konnte das gleiche Verhalten wieder reproduziert werden. Daraufhin wurde das Test-Script
um die Anzeige der aktuellen Speicherverwendung des Payara-Servers erweitert und diese zeitgleich zu beobachten. Diese
Auswertung zeigte, dass der Server mit ca. 1500 MB RSS Nutzung an seine Grenzen stößt. Diese Grenzen wurde durch die
Konfigurationsänderung im Payara-Server von \texttt{-Xmx512m} auf \texttt{-Xmx4096m} nach oben verschoben. Nun werden
ca. 60 Aufrufe des Scripts benötigt, damit der Server nicht mehr reagiert. Hierbei wird aber kein OutOfMemoryError
in der Log-Datei protokolliert und der Server verwendet nun ca. 4700 MB RSS. Bei allen Tests war noch mehr als die
Hälfte des verfügbaren Arbeitsspeichers unbenutzt.
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.
12237 Aufrufe direkt nach Neustart
12219 Aufrufe nach Redeploy
62-63 Aufrufe direkt nach dem Start über IntelliJ.
\subsection{Caching im OpenJPA}
\label{sec:performance-checking:investigation-application:caching-openjpa}
@ -50,31 +62,130 @@ Die Cache-Einstellung von OpenJPA werden über die zwei Einstellungen \texttt{op
\texttt{openjpa.QueryCache} konfiguriert. Bei beiden Einstellungen kann zuerst einmal über ein einfaches Flag
\textit{true} und \textit{false} entschieden werden ob der Cache aktiv ist. Zusätzlich kann über das Schlüsselwort
\textit{CacheSize} die Anzahl der Elementen im Cache gesteuert werden. Wird diese Anzahl erreicht, dann werden zufällige
Objekte aus dem Cache entfernt und in eine SoftReferenceMap übertragen. Dort
Objekte aus dem Cache entfernt und in eine SoftReferenceMap übertragen.
Vor jedem Test-Lauf wurde die Domain beendet und komplett gestartet, um mit einer frischen Instan zu beginnen. Hierbei
ist aufgefallen, dass fast immer 62 Abfragen zur Startup-Phase dazugehört haben, unabhängig von den konfigurierten
Cache Einstellungen.
Zuerst wurden die Test mit deaktivierten Cache durchgeführt. Die Tabelle \ref{tab:MeasureOJPAinactive} zeigt, dass
wie zu erwarten, der erste Aufruf bedeutend länger dauert wie alle Nachfolgenden.
Ebenfalls sieht man eindeutig, dass die Anzahl der Anfragen nach dem ersten Aufruf immer die gleiche Anzahl besitzen.
Der Speicherbedarf steht auch sehr gleichmässig, was nicht recht ins Bild passt, da hier keine Objekte im Cache
gehalten werden sollen.
\begin{table}[h!]
\centering
\begin{tabular}{|r|r|r|r|r|r|r|r|}
\hline
& \multicolumn{3}{|c|}{Aufrufzeit} & & \multicolumn{3}{|c|}{RSS} \\
\hline
\# & min & avg & max & Queries & davor & danach & diff \\
\hline
1 & 395 & 578 & 1312 & 12237 & 747.15 & 924.88 & 177.73 \\
2 & 353 & 375 & 464 & 12080 & 924.51 & 1027.75 & 103,24 \\
3 & 286 & 345 & 535 & 12080 & 1018.21 & 1145.36 & 127.15 \\
4 & 291 & 307 & 340 & 12080 & 1129.91 & 1239.75 & 109,84 \\
\hline
\end{tabular}
\caption{Messung ohne OpenJPA-Cache}
\label{tab:MeasureOJPAinactive}
\end{table}
Bei aktivierten Cache mit einer Cache-Größe von 1000 Elemente, dauerte der erst Aufruf minimal länger aber schon die
weiteren Aufrufe waren im Schnitt um 100 ms kürzer. Entsprechend sind auch die Anfragen an die Datenbank zurückgegangen.
Und das anwachsen des Speicherbedarfs konnte reduziert werden.
\begin{table}[h!]
\centering
\begin{tabular}{|r|r|r|r|r|r|r|r|}
\hline
& \multicolumn{3}{|c|}{Aufrufzeit} & & \multicolumn{3}{|c|}{RSS} \\
\hline
\# & min & avg & max & Queries & davor & danach & diff \\
\hline
1 & 277 & 469 & 1506 & 7206 & 764,21 & 859.96 & 95.75 \\
2 & 228 & 269 & 384 & 6767 & 848,64 & 908,44 & 59.80 \\
3 & 224 & 238 & 299 & 6656 & 898.71 & 949.94 & 51.23 \\
4 & 214 & 235 & 325 & 6671 & 936.70 & 999.49 & 62.79 \\
\hline
\end{tabular}
\caption{Messung mit OpenJPA-Cache und Größe auf 1000}
\label{tbl:MeasureOJPAactive}
\end{table}
Wenn die Cache-Größe erhöht wird, zeigt sich auf den ersten Blick ein noch besseres Bild ab. 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 nun nur noch 6 Anfragen pro Seitenaufruf an die Datenbank gestellt, wodurch die Laufzeit
im Schnitt nochmal um 100 ms beschleunigt werden konnte.
\begin{table}[h!]
\centering
\begin{tabular}{|r|r|r|r|r|r|r|r|}
\hline
& \multicolumn{3}{|c|}{Aufrufzeit} & & \multicolumn{3}{|c|}{RSS} \\
\hline
\# & min & avg & max & Queries & davor & danach & diff \\
\hline
1 & 178 & 347 & 1507 & 1419 & 752.10 & 862.38 & 110,28 \\
2 & 126 & 152 & 232 & 60 & 853.72 & 875.21 & 21.49 \\
3 & 130 & 134 & 142 & 60 & 880.08 & 880.94 & 0,86 \\
4 & 125 & 128 & 135 & 60 & 865.36 & 897.96 & 32.60 \\
\hline
\end{tabular}
\caption{Messung mit OpenJPA-Cache und Größe auf 10000}
\label{tbl:MeasureOJPAactivebigger}
\end{table}
Bei aktivierten Caching benötigt der erste Aufruf ca. 1500 msec, die nachfolgenden liegen um die 250 msec.
\mytodos{pin und unpin noch mit einbringen? SoftReferenceMap nochmal genau durchleuchte, laut doku entfällt dort nichts
wenn kein Timeout auf der Klasse definiert ist}
Kein unterschied feststellbar, nachgeprüft ob die Einstellung richtig deaktiviert sind in der Datei:
domain1/applications/WedekindJSF-1.0.0/WEB-INF/lib/classes/META-INF/persistence.xml
\subsection{Caching im \ac{JPA}}
\label{sec:performance-checking:investigation-application:caching-jpa}
Die Cache-Einstellung von JPA werden übe die Einstellungen \texttt{eclipselink.query-results-cache}, ... konfiguriert.
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
Bei deaktiviertem Caching benötigt der erste Aufruf ca. 2400 ms, die nachfolgenden liegen bei ca. 600 ms.
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
Bei aktivierten Caching benötigt der erste Aufruf ca. 1500 ms, die nachfolgenden liegen bei ca. 600 ms.
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
Nach den 10 Aufrufen, sind jedesmal 12080 neue Aufrufe im Datenbanklog verzeichnet gewesen, bei aktiven und inaktiven Caching.
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.
Bei WEAK hat sich die Speichernutzung nur um 5MB gesteigert
\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.
\subsection{Caching in \ac{EJB}}
\label{sec:performance-checking:investigation-application:caching-ejb}
\mytodos{nach aktuellen Stand, sind die gleichen Werte wie oben zu erkennen}
\subsection{Abfragen JPQL}
\label{sec:performance-checking:investigation-application:query-jpql}

BIN
thesis.pdf
View file

Binary file not shown.

4
thesis.tex
View file

@ -14,7 +14,7 @@
\input{marco-galster-config}
\input{classicthesis-config}
\renewcommand{\myThesisType}{Bachelorarbeit\xspace}
\renewcommand{\myTime}{01. Januar 2024\xspace}
\renewcommand{\myTime}{22. Juli 2024\xspace}
\renewcommand{\myVersion}{version 1.0\xspace}
% https://en.wikibooks.org/wiki/LaTeX/Source_Code_Listings
@ -68,7 +68,7 @@
%\cleardoublepage\include{frontbackmatter/Acknowledgments}
\cleardoublepage\include{frontbackmatter/Contents}
\cleardoublepage\include{frontbackmatter/Figures}
%\cleardoublepage\include{frontbackmatter/Tables}
\cleardoublepage\include{frontbackmatter/Tables}
\cleardoublepage\include{frontbackmatter/Listings}
\cleardoublepage\include{frontbackmatter/thesis/Acronyms}
%*************************************************************************