
\chapter{Performance-Untersuchung}
\label{ch:performance-checking}

\section{Auswertung des Systems}
\label{sec:performance-checking:system}

\mytodos{Hier die Auswertung des Produktionsservers unterbringen}

\section{Statistiken im PostgreSQL auswerten}
\label{sec:performance-checking:postgresql-statistics}

\mytodos{Logs auswerten, am besten vom Produktionsserver. Ebenfalls sollte man die Webseite
prüfen, die den Cache von OpenJPE auswerten}

\section{Überprüfung des PostgreSQL und Servers}
\label{sec:performance-checking:postgresql-checking}

\mytodos{Konfiguration vom Produktionsserver prüfen}

\section{Einbau und Aktivieren von Performance-Messung}
\label{sec:performance-checking:performance-measure}

\mytodos{Einbau der Messungen direkt in die Webseite bzw. in ein Log}

\section{Untersuchung der Anwendung}
\label{sec:performance-checking:investigation-application}

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}

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

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.

\subsection{Caching im OpenJPA}
\label{sec:performance-checking:investigation-application:caching-openjpa}

Die Cache-Einstellung von OpenJPA werden über die zwei Einstellungen \texttt{openjpa.DataCache} und
\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 


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.

Bei deaktiviertem Caching benötigt der erste Aufruf ca. 2400 ms, die nachfolgenden liegen bei ca. 600 ms. 

Bei aktivierten Caching benötigt der erste Aufruf ca. 1500 ms, die nachfolgenden liegen bei ca. 600 ms.

Nach den 10 Aufrufen, sind jedesmal 12080 neue Aufrufe im Datenbanklog verzeichnet gewesen, bei aktiven und inaktiven Caching.

\subsection{Caching in \ac{EJB}}
\label{sec:performance-checking:investigation-application:caching-ejb}

\subsection{Abfragen JPQL}
\label{sec:performance-checking:investigation-application:query-jpql}

\subsection{Abfragen Criteria API}
\label{sec:performance-checking:investigation-application:query-criteria-api}

\subsection{materialized views}
\label{sec:performance-checking:investigation-application:materialized-views}

\subsection{cached queries}
\label{sec:performance-checking:investigation-application:cached-query}

\subsection{Umgestalten der Datenbanktabellen}
\label{sec:performance-checking:investigation-application:new-table}

\subsection{Verkleinerung der Abfragen}
\label{sec:performance-checking:investigation-application:smaller-query}

