Dialy CheckIn

chapters/thesis/chapter04.tex

@@ -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
+Für die Tests wird ein aktuelles Manjaro-System mit frisch installierten Payara als Serverhost und der IntelliJ IDEA
-die 2 vorherigen und beim 4ten Aufruf ist der Payara-Server mit einer OutOfMemoryError-Exception im Java-Heapspeicher
+als Entwicklungsumgebung verwendet. Der Computer ist mit einer Intel CPU i7-12700K, 32 GB Arbeitsspeicher und einer SSD
-ausgestiegen und musste per Kill-Befehl abgeschossen werden.
+als Systemfestplatte ausgestattet.
-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}
 
-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 einem Neustart des Servers, konnte das gleiche Verhalten wieder reproduziert werden. Daraufhin wurde das Test-Script
-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.
+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}
 

thesis.tex

@@ -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}
 %*************************************************************************