diff --git a/chapters/thesis/chapter04.tex b/chapters/thesis/chapter04.tex index 18aef70..9852e64 100644 --- a/chapters/thesis/chapter04.tex +++ b/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 -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 -Xmx512m -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} diff --git a/thesis.pdf b/thesis.pdf index 0794464..bf4ac56 100644 Binary files a/thesis.pdf and b/thesis.pdf differ diff --git a/thesis.tex b/thesis.tex index 3a632e3..1f85688 100644 --- a/thesis.tex +++ b/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} %*************************************************************************