Dialy CheckIn
This commit is contained in:
parent
a63f4414dd
commit
418b925b9f
3 changed files with 133 additions and 22 deletions
|
@ -22,6 +22,7 @@ prüfen, die den Cache von OpenJPE auswerten}
|
||||||
\label{sec:performance-checking:performance-measure}
|
\label{sec:performance-checking:performance-measure}
|
||||||
|
|
||||||
\mytodos{Einbau der Messungen direkt in die Webseite bzw. in ein Log}
|
\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}
|
\section{Untersuchung der Anwendung}
|
||||||
\label{sec:performance-checking:investigation-application}
|
\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
|
Nun werden die unterschiedlichen Schichten betrachtet und möglichen Performance-Verbesserungen untersucht und deren
|
||||||
Vor"= und Nachteile herausgearbeitet.
|
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}
|
\subsection{Caching im OpenJPA}
|
||||||
\label{sec:performance-checking:investigation-application:caching-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
|
\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{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
|
\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
|
\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}
|
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}}
|
\subsection{Caching im \ac{JPA}}
|
||||||
\label{sec:performance-checking:investigation-application:caching-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}}
|
\subsection{Caching in \ac{EJB}}
|
||||||
\label{sec:performance-checking:investigation-application:caching-ejb}
|
\label{sec:performance-checking:investigation-application:caching-ejb}
|
||||||
|
|
||||||
|
\mytodos{nach aktuellen Stand, sind die gleichen Werte wie oben zu erkennen}
|
||||||
|
|
||||||
\subsection{Abfragen JPQL}
|
\subsection{Abfragen JPQL}
|
||||||
\label{sec:performance-checking:investigation-application:query-jpql}
|
\label{sec:performance-checking:investigation-application:query-jpql}
|
||||||
|
|
||||||
|
|
BIN
thesis.pdf
BIN
thesis.pdf
Binary file not shown.
|
@ -14,7 +14,7 @@
|
||||||
\input{marco-galster-config}
|
\input{marco-galster-config}
|
||||||
\input{classicthesis-config}
|
\input{classicthesis-config}
|
||||||
\renewcommand{\myThesisType}{Bachelorarbeit\xspace}
|
\renewcommand{\myThesisType}{Bachelorarbeit\xspace}
|
||||||
\renewcommand{\myTime}{01. Januar 2024\xspace}
|
\renewcommand{\myTime}{22. Juli 2024\xspace}
|
||||||
\renewcommand{\myVersion}{version 1.0\xspace}
|
\renewcommand{\myVersion}{version 1.0\xspace}
|
||||||
|
|
||||||
% https://en.wikibooks.org/wiki/LaTeX/Source_Code_Listings
|
% https://en.wikibooks.org/wiki/LaTeX/Source_Code_Listings
|
||||||
|
@ -68,7 +68,7 @@
|
||||||
%\cleardoublepage\include{frontbackmatter/Acknowledgments}
|
%\cleardoublepage\include{frontbackmatter/Acknowledgments}
|
||||||
\cleardoublepage\include{frontbackmatter/Contents}
|
\cleardoublepage\include{frontbackmatter/Contents}
|
||||||
\cleardoublepage\include{frontbackmatter/Figures}
|
\cleardoublepage\include{frontbackmatter/Figures}
|
||||||
%\cleardoublepage\include{frontbackmatter/Tables}
|
\cleardoublepage\include{frontbackmatter/Tables}
|
||||||
\cleardoublepage\include{frontbackmatter/Listings}
|
\cleardoublepage\include{frontbackmatter/Listings}
|
||||||
\cleardoublepage\include{frontbackmatter/thesis/Acronyms}
|
\cleardoublepage\include{frontbackmatter/thesis/Acronyms}
|
||||||
%*************************************************************************
|
%*************************************************************************
|
||||||
|
|
Loading…
Reference in a new issue