Daily CheckIn

chapters/thesis/appendix02_timing.sh

@@ -7,15 +7,24 @@ set -euo pipefail
 
 main() {
     {
-        echo -e "URL\tRuns\tStDev\tMin (ms)\tAvg (ms)\tMax (ms)"
+        local maxLen=0
         for url in ${@:2}; do
-            get_statistics $url $1
+            local size=${#url}
+            if [[ $size -gt $maxLen ]]
+                then maxLen=$size
+            fi
+        done
+
+        printf "%-${maxLen}s   %+4s %+5s %+9s %+9s %+9s %+9s\n" "URL" "Runs" "StDev" "Min (ms)" "Avg (ms)" "Max (ms)" "1st (ms)"
+        for url in ${@:2}; do
+            get_statistics $url $1 $maxLen
         done
     } #| column -s $'\t' -t
 }
 
 get_statistics() {
     # Initialice the variables
+    local first=-1
     local min=1000000000
     local max=0
     local dur=0
@@ -23,13 +32,17 @@ get_statistics() {
     local spin=0
     local spiner=('-' '\' '|' '/')
 
-    echo -ne "$1\t "
+    printf "%-${maxLen}s    " $1
+    #echo -ne "$1\t "
 
     # repeat for the defined counts the url calling
     for i in $(seq 1 $2); do
         echo -ne "\b${spiner[$spin]}"
         spin=$(( (spin+1) % 4 ))
         local gp=$(($(get_posts $1)/1000000)) # from ns to ms
+        if [[ $first -lt 0 ]]
+            then first=$gp
+        fi
         if [[ $gp -gt $max ]]
             then max=$gp
         fi
@@ -45,7 +58,8 @@ get_statistics() {
     local stdev=$( echo "sqrt(($durQ / $2) - $avgPow)" | bc )
 
     # output the statistic values
-    echo -e "\b$2\t$stdev\t$min\t$avg\t$max"
+    printf "\b%+4s %+5s %+9s %+9s %+9s %+9s\n" $2 $stdev $min $avg $max $first
+    #echo -e "\b$2\t$stdev\t$min\t$avg\t$max\t$first"
 }
 
 get_posts() {

chapters/thesis/chapter04.tex

@@ -50,29 +50,12 @@ 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
+Als Grundlage für die Vergleiche wurden eine Messung durchgeführt, bei der alle Caches deaktiviert wurden und keine
-12219 Aufrufe nach Redeploy
+Änderung am Code vorgenommen wurde. Das Ergebnis dieser Messung ist in \ref{tab:MeasureWithoutCache} zu finden. Diese
-
+zeigen auch direkt ein erwartetes Ergebnis, dass der erste Aufruf bedeutend länger dauert als die Nachfolgenden.
-62-63 Aufrufe direkt nach dem Start über IntelliJ.
-
-\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.
-
-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
+Der Speicherbedarf steigt auch relative gleichmässig, was nicht recht ins Bild passt, da hier keine Objekte im Cache
-gehalten werden sollen.
+gehalten werden sollten.
 
 \begin{table}[h!]
     \centering
@@ -88,13 +71,28 @@ gehalten werden sollen.
         4 & 291 & 307 &  340 & 12080 & 1129.91 & 1239.75 & 109,84 \\
         \hline
     \end{tabular}
-    \caption{Messung ohne OpenJPA-Cache}
+    \caption{Messung ohne Caches}
-    \label{tab:MeasureOJPAinactive}
+    \label{tab:MeasureWithoutCache}
 \end{table}
 
-Bei aktivierten Cache mit einer Cache-Größe von 1000 Elemente, dauerte der erst Aufruf minimal länger aber schon die
+Vor jedem weiteren Test-Lauf wurde die Domain beendet und komplett neugestartet, um mit einer frischen Instanz zu
-weiteren Aufrufe waren im Schnitt um 100 ms kürzer. Entsprechend sind auch die Anfragen an die Datenbank zurückgegangen.
+beginnen. Hierbei ist aufgefallen, dass fast immer 62 Abfragen zur Startup-Phase dazugehört haben, unabhängig von den
-Und das anwachsen des Speicherbedarfs konnte reduziert werden.
+konfigurierten Cache Einstellungen.
+
+\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.
+
+Zuerst wird mit aktivierten Cache mit einer Cache-Größe von 1000 Elemente getestet. Wie in \ref{tbl:MeasureOJPAactive}
+zu sehen, dauert auch hier der erste Aufruf minimal länger als ohne akivierten Cache. Alle Nachfolgenden Aufrufe
+wiederrum sind um 100ms schneller in der Verarbeitung. Auch bei der Anzahl der Anfragen an die Datenbank kann mehr den
+Rückgang der Anfragen sehr gut sehen. Aktuell kann die Verringerung des wachsenden Speicherbedarfs nur nicht erklärt
+werden.
 
 \begin{table}[h!]
     \centering
@@ -114,10 +112,11 @@ Und das anwachsen des Speicherbedarfs konnte reduziert werden.
     \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
+Bei einer erhöhten Cache-Größe, zeigt sich auf den ersten Blick ein noch besseres Bild ab, wie in
-der Laufzeit mit geringerer Cache-Größe, aber schon die Anfragen an die Datenbank gehen drastisch zurück. Bei den
+\ref{tbl:MeasureOJPAactivebigger} ersichtlich ist. Der erste Aufruf entspricht der Laufzeit mit geringerer Cache-Größe,
-weiteren Aufrufen werden nun nur noch 6 Anfragen pro Seitenaufruf an die Datenbank gestellt, wodurch die Laufzeit
+aber schon die Anfragen an die Datenbank gehen drastisch zurück. Bei den weiteren Aufrufen werden im Schnitt nun nur
-im Schnitt nochmal um 100 ms beschleunigt werden konnte.
+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
@@ -137,9 +136,9 @@ im Schnitt nochmal um 100 ms beschleunigt werden konnte.
     \label{tbl:MeasureOJPAactivebigger}
 \end{table}
 
-
 \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}
+\mytodos{kurzes Fazit fehlt noch!}
 
 \subsection{Caching im \ac{JPA}}
 \label{sec:performance-checking:investigation-application:caching-jpa}
@@ -184,7 +183,25 @@ Anzahl der Abfragen an die Datenbank drastisch reduziert werden. Selbst die Lauf
 \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}
+Die Cache-Einstellungen des \ac{EJB} sind in der Admin-Oberfläche des Payara-Servers zu erreichen. Hier
+
+\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 & 416 & 554 & 1269 & 12237 &  840.31 &  998.07 & 157.76 \\
+        2 & 299 & 394 &  749 & 12080 &  973.20 & 1101.37 & 128.17 \\
+        3 & 293 & 324 &  382 & 12080 & 1092.00 & 1192.87 & 100.87 \\
+        4 & 281 & 318 &  398 & 12080 & 1191.25 & 1305.29 & 114.04 \\
+        \hline
+    \end{tabular}
+    \caption{Messung mit OpenJPA-Cache und Größe auf 10000}
+    \label{tbl:MeasureEJBAactive}
+\end{table}
 
 \subsection{Abfragen JPQL}
 \label{sec:performance-checking:investigation-application:query-jpql}