Daily CheckIn

chapters/thesis/chapter05.tex

@@ -22,11 +22,21 @@ Konfigurationsänderung im Payara-Server von \texttt{-Xmx512m} auf \texttt{-Xmx4
 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 des Computers ungenutzt.
-\mytodos{-Xmx definiert die Größe des Verwendbaren Heapspeichers}
 
+Mit der Konfiguration \texttt{-Xmx} wird der maximal verwendbare Heap"=Speicher in der \ac{JVM} definiert. 
 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.
 
+Für alle nachfolgenden Messungen wird das Skript \ref{ap:calling_script} verwendet, welches die einzelnen Aufrufe
+steuert. Die Ergebnisse werden in eine Tabelle überführt, wie in der Tabelle \ref{tbl:measure-without-cache}.
+Hierbei werden die Aufrufzeiten der Webseite aus dem Skript für die Zeitmessung mit Mindest"=, Durchschnitt"= und
+Maximalzeit aufgenommen, hierbei ist eine kürzere Zeit besser. Zusätzlich wird die Anzahl der aufgerufenen SQL Abfragen
+ermitteln, auch hier gilt, dass weniger Aufrufe besser sind. Als letztes wird noch der verwendete Arbeitsspeicher
+vom \textit{Glassfish}"=Server vor und nach dem Aufruf ermittelt und die Differenz gebildet, hierbei sollte im besten
+Fall die Differenz bei 0 liegen. Dieser Aufbau gilt für alle weiteren Messungen. Zusätzlich werden noch die Laufzeiten
+der \ac{JSF} ermittelt und die durchschnittlichen Zeiten mit in der Tabelle dargestellt, und auch hier ist es besser,
+wenn die Zeiten kürzer sind.
+
 Als Grundlage für die Vergleiche wurden eine Messung durchgeführt, bei der alle Caches deaktiviert wurden und keine
 Änderung am Code vorgenommen wurde. Das Ergebnis dieser Messung ist in \ref{tbl:measure-without-cache} zu finden. Diese
 zeigen auch direkt ein erwartetes Ergebnis, dass der erste Aufruf bedeutend länger dauert als die Nachfolgenden.
@@ -34,8 +44,6 @@ Ebenfalls sieht man eindeutig, dass die Anzahl der Anfragen nach dem ersten Aufr
 Der Speicherbedarf steigt auch relative gleichmässig, was nicht recht ins Bild passt, da hier keine Objekte im Cache
 gehalten werden sollten.
 
-\mytodos{hier noch beschreiben, wie die Werte zu interpretieren sind, und hervorheben, dass dies nun für alle Tabellen so gilt!}
-\mytodos{hier noch text einfügen, der erklärt wie die Spalten zu werten sind, also Aufrufzeit ist kürzer gleich besser}
 \mytodos{Diese Tabelle vielleicht auch einfach komplett streichen, da der Datenbestand anders ist, und das wichtigste
 die Zeit der SQL-Abfragen nicht sichtbar ist}
 
@@ -96,8 +104,6 @@ der Anzahl aller vorhandenen Dokumente.
     \label{tbl:measure-without-cache-docker}
 \end{table}
 
-\mytodos{die Reihenfolge der Sektion dem Schichtmodel anpassen}
-
 \section{Umgestalten der Datenbanktabellen}
 \label{sec:performance-investigation-application:new-table}
 
@@ -179,7 +185,9 @@ beschleunigt werden konnte.
 
 \mytodos{Untersuchung mit deaktivieren SoftReference fehlt noch}
 
-\mytodos{kurzes Fazit fehlt noch, anzahl der Queries für unterabfragen gehen auf 0 bzw. bleiben bei 400!}
+Die Vergleich zeigt, dass der Cache eine gute Optimierung bringt, aber dies nur dann gut funktioniert, wenn immer
+wieder die gleichen Objekte ermittelt werden. Sobald die Anfragen im Wechsel gerufen werden oder einfach nur der Menge
+der Objekte den Cache übersteigt, fällt die Verbesserung gering aus.
 
 \section{cached queries}
 \label{sec:performance-investigation-application:cached-query}
@@ -213,43 +221,42 @@ abfragt.
 
 \mytodos{muss noch umgebaut werden, falsche Konfiguration erwischt}
 
+%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
 
-Die Cache-Einstellungen von \ac{JPA} werden über mehrere Einstellungen konfiguriert. Anhand von
+%Der geteilte Cache, der für die Dauer der persistenten Einheit (EntityManagerFactory oder der Server) vorhanden ist,
-\texttt{eclipselink.query-results-cache} wird definiert, dass die Ergebnisse von benannten Abfragen im Cache
+%kann über \texttt{eclipselink.cache.shared.default} gesteuert werden. Dieser kann nur aktiviert oder deaktiviert werden.
-gespeichert werden. Für den Zugriff in den Cache, wird neben den Namen noch die übergebenen Parameter
+%% https://wiki.eclipse.org/EclipseLink/Examples/JPA/Caching
-berücksichtigt.
-% https://eclipse.dev/eclipselink/documentation/2.5/concepts/cache008.htm
 
-Der geteilte Cache, der für die Dauer der persistenten Einheit (EntityManagerFactory oder der Server) vorhanden ist,
+%Mit \texttt{eclipselink.cache.size.default} wird die initiale Größe des Caches definiert, hierbei ist der Standardwert
-kann über \texttt{eclipselink.cache.shared.default} gesteuert werden. Dieser kann nur aktiviert oder deaktiviert werden.
+%100. Die Objekt werden nicht direkt aus dem Cache entfernt, sondern erst nachdem der \ac{GC} diese freigeben hat.
-% https://wiki.eclipse.org/EclipseLink/Examples/JPA/Caching
+%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
 
-Mit \texttt{eclipselink.cache.size.default} wird die initiale Größe des Caches definiert, hierbei ist der Standardwert
+%Um den Cache zu deaktivieren wurden beiden Einstellungen auf \textit{false} gestellt, die Größe auf 0 und der Cache-Typ
-100. Die Objekt werden nicht direkt aus dem Cache entfernt, sondern erst nachdem der \ac{GC} diese freigeben hat.
+%auf \textit{NONE}. Hierbei lag die maximale gemessene Laufzeit des ersten Aufrufs bei ca. 1300 ms und es wurden 12219
-Zusätzlich wird über \texttt{eclipselink.cache.type.default} die Art des Caching gesteuert. Die Einstellung mit dem
+%Abfragen an die Datenbank gestellt. Bei den nachfolgenden Aufrufe lag die Aufrufzeit im Durchschnitt bei 350 ms und
-höchsten Speicherbedarf ist \textit{FULL}, bei dem alle Objekte im Cache bleiben, außer sie werden explizit gelöscht.
+%12080 Abfragen.
-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
 
-Um den Cache zu deaktivieren wurden beiden Einstellungen auf \textit{false} gestellt, die Größe auf 0 und der Cache-Typ
+%Um den Cache wieder zu aktivieren wurden die Einstellungen auf \textit{true} gestellt, die Größe auf den Standardwert
-auf \textit{NONE}. Hierbei lag die maximale gemessene Laufzeit des ersten Aufrufs bei ca. 1300 ms und es wurden 12219
+%von 100 und der Cache-Type auf \textit{SOFT} gestellt. Hierbei wurde eine maximale Laufzeit beim ersten Aufruf ebenfalls
-Abfragen an die Datenbank gestellt. Bei den nachfolgenden Aufrufe lag die Aufrufzeit im Durchschnitt bei 350 ms und
+%von 1300 ms gemessen und es wurden 12218 Abfragen abgesetzt. Bei den nachfolgenden Aufrufen lag die Aufrufzeit im
-12080 Abfragen.
+%Durchschnitt bei 340 ms.
 
-Um den Cache wieder zu aktivieren wurden die Einstellungen auf \textit{true} gestellt, die Größe auf den Standardwert
+%Bei WEAK hat sich die Speichernutzung nur um 5MB gesteigert
-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?}
 
-\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.
-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.
 
 \section{Caching in \ac{EJB}}
 \label{sec:performance-investigation-application:caching-ejb}
@@ -538,12 +545,13 @@ Nach dem Anpassungen haben sich dann die Werte aus \ref{tbl:measure-materialized
 \section{Java Server Faces}
 \label{sec:performance-investigation-application:java-server-faces}
 
-\mytodos{Zeitmessungen innerhalb der Anwendung über einen Flamegraphs darstellten https://www.brendangregg.com/flamegraphs.html}
+%\mytodos{Zeitmessungen innerhalb der Anwendung über einen Flamegraphs darstellten https://www.brendangregg.com/flamegraphs.html}
-\mytodos{Diese Zeitmessung vielleicht noch ins Obere Kapitel ala Ausgangspunkt verschieben}
+%\mytodos{Diese Zeitmessung vielleicht noch ins Obere Kapitel ala Ausgangspunkt verschieben}
 
-Wie in \ref{sec:performance-checking:performance-measure} beschrieben wurde, die Protokollierung für das erstellen einer
+Wie in \ref{sec:performance-checking:performance-measure} beschrieben wurde, ist die Protokollierung für das erstellen
-Webseite aktiviert. Bei komplett deaktivierten Cache sieht man, dass bei der Dokumentenliste der größte Zeitfaktor beim
+einer Webseite aktiviert. Bei komplett deaktivierten Cache sieht man, dass bei der Dokumentenliste der größte Zeitfaktor 
-Render der Sicht auftritt. Wenn man nun noch die Abfrage auf die Materialized-View umstellt, ist es noch auffälliger.
+beim Render der Sicht auftritt. Wenn man nun noch die Abfrage auf die Materialized-View umstellt, ist es noch
+auffälliger.
 
 \begin{table}[h!]
     \centering
@@ -576,7 +584,10 @@ Daher ist eine Umstellung auf statische Webseiten nicht sinnvoll.
 \section{Client basierte Webseiten}
 \label{sec:performance-investigation-application:client-side-rendering}
 
-\mytodos{Beschreiben, dass alles auf dem client geschickt wird, und dort alles gerendert und sortiert wird,
+Als weitere Möglichkeit könnte man die Webseite so umbauen, dass die Daten erst im Nachgang über eine AJAX-Anfrage
-damit aber schwächere Clients ausgeschlossen werden!
+ermittelt und die Sortierung und Aufteilung im Client durchgeführt wird. Hierbei wird aber je nach Datenmenge ein
-Hätte aber Vorteil für die Kosten des Servers, da dieser schwächer ausgelegt werden könnte und damit Geld einzusparen
+großer Speicher am Client benötigt und die Rechenleistung wird auf den Client verschoben.
-wäre. !!!! Der Punkt könnte auch unter QueryCache gelagert werden !!!!}
+
+Dies wiederrum ist ein Vorteil für den Serverbetreiber, da durch die Verschiebung weniger Rechenleistung am Server
+benötigt wird. Gleichzeitig würde man damit wiederrum schwächere Clients, wie Smartphones, aussperren, da bei diesem
+die notwendige Rechenleistung fehlt, um die Webseite in annehmbarer Zeit darzustellen.

frontbackmatter/thesis/Acronyms.tex

@@ -29,6 +29,7 @@
   \acro{UML}{Unified Modeling Language}
   \acro{GB}{Gigabyte}
   \acro{SQL}{Structured Query Language}
+  \acro{JVM}{Java Virtual Machine}
 \end{acronym}
 
 \cleardoublepage