Dialy CheckIn

chapters/thesis/chapter01.tex

@@ -6,7 +6,7 @@
 Die Akzeptanz und damit die Verwendung einer Software hängt von verschiedenen Kriterien
 ab. Hierbei ist neben der Stabilität und der Fehlerfreiheit die Performance beziehungsweise
 die Reaktionszeit der Software ein sehr wichtiges Kriterium. Hierfür muss sichergestellt
-werden, dass die Anwendung immer in kurzer Zeit reagiert oder entsprechende Anzeigen dargestellt
+werden, dass die Anwendung immer in kurzer Zeit reagiert oder entsprechende Anzeigen dargestellt wird
 um eine längere Bearbeitung anzuzeigen.
 
 %\section{Motivation}
@@ -44,7 +44,7 @@ kommentiert wurde.
 
 Um jenes zu verändern entstand das Projekt >>Edition der Korrespondenz Frank Wedekind als Online"=Volltextdatenbank<<,
 welches bei der EFFW angesiedelt ist und als Kooperationsprojekt an der Johannes  Gutenberg"=Universität Mainz,
-der Hochschule Darmstadt und der Fernuni Hagen umgesetzt und durch die Deutsch Forschungsgemeinschaft (Bonn) gefördert wird.
+der Hochschule Darmstadt und der Fernuni Hagen umgesetzt und durch die Deutsche Forschungsgemeinschaft (Bonn) gefördert wird.
 
 Das entstandene Pilotprojekt ist eine webbasiert Anwendung, die aktuell unter \url{http://briefedition.wedekind.h-da.de}
 eingesehen werden kann. Hierbei wurden sämtliche bislang bekannte Korrespondenzen in dem System digitalisiert. Die
@@ -64,7 +64,7 @@ Performance der Oberfläche. Auf Grund der langen Abfragedauer des Datenbestande
 Das Ziel der Arbeit ist es, die Abfragedauer zu verringern, wodurch die Performance der Oberfläche signifikant
 verbessert wird.
 
-Hierbei ist auch ein Vergleich mit anderen Technologien angedacht.
+Hierbei ist auch ein Vergleich mit anderen Techniken angedacht.
 
 \section{Gliederung}
 \label{sec:intro:structure}
@@ -73,19 +73,24 @@ Zu Begin der Arbeit werden im Kapitel \ref{ch:basics} die Struktur und der grund
 erklärt. Hierbei wird aufgezeigt an welchen Stellen es immer wieder zu Unstimmigkeiten kommen kann und wie diese zu
 überprüfen sind.
 
-Nachfolgenden wird im Kapitel \ref{ch:concept} die Konzepte vorgestellt, die die Seiten ermitteln, die eine schlechte
+Nachfolgenden wird im Kapitel \ref{ch:concept} die Konzepte vorgestellt, die die Stellen ermitteln, die eine schlechte
 Performance aufweisen und optimiert werden sollen.
-Hierbei ist zusätzlich ein Blick auf andere Frameworks sinnvoll, um dort aus den bekannten Anomalien zu lernen und
-deren Lösungsansatz zu überprüfen ob dieser angewandt werden kann.
+Hierzu gehören zum einen die Einstellungen der verwendeten Software, und zum anderen der Aufbau und die verwendeten
+Techniken in der Anwendung. Diese Techniken werden im weiteren Verlauf nochmal überprüft ob eine alternative Lösung
+einen performantere Umsetzung bringen kann.
 
 Bei den Performance"=Untersuchung in Kapitel \ref{ch:performance-checking} werden nun die Konzepte angewandt, um
-die Problemstellen zu identifizieren. Diese werden dann bewertet, unter den Gesichtspunkten ob eine Optimierung an
-dieser Stelle sinnvoll ist, oder ob der Arbeitsaufwand dafür zu enorm ist.
+die Umgebung selbst zu Untersuchen und die dort bekannten Probleme zu ermitteln. Diese werden direkt bewertet, unter den
+Gesichtspunkten, ob eine Optimierung an dieser Stelle sinnvoll ist, oder ob der Arbeitsaufwand dafür zu enorm ist.
+Zusätzlich werden noch die Vorbereitungen und die angepassten Konfigurationen für die nachfolgenden
+Performance"=Untersuchung der Anwendung aufzeigt.
 
-Nach der Entscheidung der Reihenfolge der zu bearbeitenden Punkte, wird im Kapitel \ref{ch:optimizing} je nach
-Problemart ein gesondertes Vorgehen der Optimierung durchgeführt, um diese zu beheben oder mindestens in einen
-akzeptablen Rahmen zu verbessern. Diese Optimierungen werden dann in der Software entsprechend der Vorgaben angepasst.
+Zuerst wird im Kapitel \ref{ch:performance-investigation-application} die Ausgangsmessung durchgeführt, hierbei werden 
+alle bekannten Caches deaktiviert und eine Messung durchgeführt.
+Dann werden Schicht für Schicht die Optimierungsmöglichkeiten aufgezeigt, umgesetzt und erneut gemessen. Diese Messung
+wird dann in Abhängigkeit zur Ausgangsmessung die Optimierung bewertet.
 
+\mytodos{Kapitel 6 ist noch zu überlegen, ob das mit 7 nicht zusammengefasst werden könnte}
 Nach der Optimierung kommt nun die Evaluierung im Kapitel \ref{ch:evaluation}, um zu überprüfen ob die Anpassungen
 die gewünschten Verbesserung in der Performance gebracht haben.
 

chapters/thesis/chapter02.tex

@@ -8,21 +8,24 @@ das jeder Wechsel einer Seite oder eine Suchanfrage als Web"=Request an den Serv
 geht durch mehrere Schichten des Server"=System bis die Antwort an den Client zurückgesendet wird, wie in 
 \ref{fig:webrequest} dargestellt.
 
-\mytodos{Unterschiedevon Glassfish und Payara eingehen, hier wird Payara verwendet glassfish ist reference-impl von oracle / payara ist commerzielle
-Lösung (In der Arbeit ausereinander halten) https://github.com/eclipse-ee4j/glassfish/}
+Es wird ab hier immer von einem \textit{Glassfish}"=Server geredet. In der Praxis wird aber ein \textit{Payara}"=Server
+verwendet. Der \textit{Glassfish}"=Server ist die Referenz"=Implementierung von Oracle, welche für Entwickler 
+bereitgestellt wird und die neuen Features unterstützt. Der \textit{Payara}"=Server ist aus dessen Quellcode entstanden,
+und ist für Produktivumgebungen gedacht, da diese mit regelmäßigen Aktualisierungen versorgt wird. In dem weiteren Text
+wird aber weiterhin der Begriff \textit{Glassfish} verwendet.
 
 Angefangen bei der Anfrage die über den Webbrowser an den Server gestellt wird und vom \textit{Glassfish}"=Server
-empfangen wird. In diesem wird anhand des definierten Routing entschieden, an welche \textit{Java Server Page} die
-Anfrage weitergeleitet und verarbeitet wird. In dieser wird die Darstellung der Webseite geladen und die Anfragen für
-den darzustellenden Datenbestand abgeschickt.
+empfangen wird. In diesem wird anhand des definierten Routing entschieden, an welchen \textit{Controller} im \ac{JSF}
+die Anfrage weitergeleitet und verarbeitet wird. In diesem wird die Darstellung der Webseite geladen und die Anfragen 
+für den darzustellenden Datenbestand abgeschickt.
 
 Die Datenanfragen werden über die \textit{\ac{EJB}} an die \textit{\ac{JPA}} weitergeleitet.
 Hier wird nun geprüft, ob die Daten aus dem \textit{OpenJPA Cache} direkt ermittelt werden können, oder ob die Abfrage
 an das unterlagerte Datenbankmanagementsystem \textit{PostgreSQL} weitergeleitet werden muss. Die ermittelten Daten vom
 DBMS werden bei Bedarf im \textit{OpenJPA Cache} aktualisiert.
 
-Das \textit{PostgreSQL} besteht aus mehreren Teilen die ineinander greifen um die Anfragen zu bearbeiten.
-Dabei sind die \textit{Memory Buffers} notwendig um den Zugriff auf die Festplatte zu reduzieren, um die Bearbeitungszeit
+Das \textit{PostgreSQL} besteht aus mehreren Teilen die ineinander greifen um die Anfragen zu bearbeiten. Dabei
+sind die \textit{Memory Buffers} notwendig um den Zugriff auf die Festplatte zu reduzieren, um die Bearbeitungszeit
 zu verringern. Um Anfragen die den Zugriff auf die Festplatte benötigen effizienter zu gestalten, bereiten die 
 \textit{Services} die Datenstrukturen auf.
 
@@ -65,7 +68,7 @@ zu verringern. Um Anfragen die den Zugriff auf die Festplatte benötigen effizie
     \label{fig:webrequest}
 \end{figure}
 
-\section{Glassfish - Enterprise Kirsten.Ritzmann@gmx.netJava Beans}
+\section{Glassfish - Enterprise Java Beans}
 \label{sec:basics:ejb}
 
 In den Java"=EE"=Anwendungen wird der \textit{Persistenzkontext} für die Anfragen vom \textit{Application"=Server}
@@ -185,4 +188,6 @@ Bei \textit{Langen} Abfragen ist die Abhandlung >>Optimizing Iceberg Queries wit
 
 Des Weiteren können über das Modul \texttt{pg\_stat\_statements} Statistiken der Aufrufe die an den Server gestellt
 wurden, ermittelt werden \citep{PostgresF27:2023}. Hierbei können die am häufigsten Aufgerufenen und die Anfragen mit
-der längsten Ausführungszeit ermittelt werden.
+der längsten Ausführungszeit ermittelt werden. Ohne zu dem zusätzlichen Modul, können die Statistiken über die
+Software \textit{pgBadger} erstellt werden. Dafür muss zusätzlich noch die Konfiguration des \textit{PostgreSQL}
+angepasst werden.

chapters/thesis/chapter03.tex

@@ -69,17 +69,15 @@ Nach aktuellem Stand beinhaltet die Datenbank ca. 5400 Briefe, für die jeweils
 werden. Diese Graphik-Dateien werden im TIFF-Format abgespeichert und benötigen zwischen 1 und 80 MB Speicherplatz.
 Dadurch kommt die Datenbank aktuell auf ca. 3,8 GB.
 
-\mytodos{Die unteren Punkte nochmal untergliedern in Performance-messen und Statistiken prüfen, dann kann mit den
-Performance-messen die unterschiedlichen Aktionen durchgeführt werden in Kapitel 4}
-
 Wie im Kapitel \ref{ch:basics} dargestellt, besteht die eigentliche Anwendung aus mehreren Schichten. Die
 PostgreSQL"=Schicht wurde schon im vorherigen Kapitel betrachtet. Daher gehen wir nun weiter nach oben in den Schichten
 vom Glassfish"=Server.
 
+\mytodos{Statistik-Webseite hier entfernen, wird aktuell nicht angewendet}
 Die OpenJPA Cache Schicht wird nun einzeln untersucht. Hierfür werden die zuerst die Cache"=Statistik für Object"=Cache
 und Query"=Cache aktiviert \citep[315]{MüllerWehr2012}. Die somit erfassten Werte, werden über eine Webseite
-bereitgestellt, um die Daten Live vom Server verfolgen zu können. Zusätzlich können diese Daten über ein Skript
-zyklisch abgefragt, gespeichert und vergleichen werden.
+bereitgestellt, um die Daten Live vom Server verfolgen zu können. Zusätzlich werden die Webseite über ein Script
+aufgerufen und die Aufrufzeiten sowie andere externe Statistiken darüber erstellt und gespeichert.
 
 In der \ac{JPA} Schicht sind die Anzahl der Entitäten im Persistence Context zu beobachten. Die Anzahl der verschiedenen
 Klassen soll ermittelt und die Statistik"=Webseite um diese Daten erweitern. Um die Daten zu ermitteln, kann der
@@ -101,30 +99,31 @@ emf.getCache().print();
 % \mytodos{\url{https://eclipse.dev/eclipselink/api/2.1/org/eclipse/persistence/jpa/JpaCache.html#getObject(java.lang.Class,%20java.lang.Object)}}
 
 Die Schicht \ac{EJB} besitzt keine Möglichkeit um eine sinnvolle Messung durchzuführen, daher wird hierfür keine
-direkte Messungen eingefügt.
+direkte Messungen eingefügt. Hier werden nur die externen Statistiken durch das Skript verwendet, um zu prüfen in 
+welchen Umfang die Umstellungen eine Veränderung im Verhalten der Webseite bewirken.
 
-Bei den \ac{JSF} wird eine Zeitmessung eingefügt. Hierfür müssen die Seiten so erweitert werden, dass zum einen die
-Zeit gemessen wird um die Daten zu ermitteln. Zum anderen wird die Zeit gemessen wie lange es dann noch dauert um die
-Seite mit den Daten zu rendern um diese an den Client auszuliefern. Diese 2 Zeiten sollen dann im Footer direkt auf der
-Seite mit dargestellt werden. Somit kann der Benutzer auch direkt sehen, wenn das laden länger gedauert hat, an welcher
-Stelle die Verzögerung aufgetreten ist.
+Bei den \ac{JSF} wird eine Zeitmessung eingefügt. Hierfür wird eine \textit{Factory} eingebaut, die sich in die
+Verarbeitung der Seiten einhängt, und damit die Zeiten für das Ermitteln der Daten, das Zusammensetzen und das 
+Render der Sicht aufgenommen werden können. Die Zeiten werden in die Log°=Datei des \textit{Glassfish}!=Servers
+hinterlegt und durch das Skript ausgewertet. Somit ist es einfach aufzuzeigen, an welcher Stelle der größte Teil
+der Verzögerung auftritt.
 
 Die Abfragen werden ebenfalls untersucht und mit verschiedenen Methoden optimiert. Hierfür werden zum einen auf native
 SQL"=Anfragen umgestellt und die Ausführungszeiten überprüft. Ebenfalls werden die Abfragen durch Criteria API erzeugt
 und dessen Ausführungszeit ermittelt.
 
-% https://www.tutorialspoint.com/jpa/jpa_jpql.htm
-
 Zusätzlich werden im SQL-Server Optimierungen vorgenommen, darunter zählen die materialized views, welche eine erweiterte
-View sind. Neben der Abfrage der Daten beinhalteten diese auch noch nicht vorberechneten Daten der Abfrage, womit diese
-viel schneller abgefragt werden können. Zusätzlich werden die cached queries überprüft ob diese eine Verbesserung der
+View ist. Neben der Abfrage der Daten beinhalteten diese auch noch vorberechneten Daten der Abfrage, womit diese viel 
+schneller abgefragt werden können. Zusätzlich werden die cached queries überprüft ob diese eine Verbesserung der
 Performance und der Abfragedauern verkürzen können.
 
-Um die Optimierungen in der Anwendung zu überprüfen, werden die Webseiten über ein Shell-Skript abgefragt. Das Skript
-ruft automatisiert die URLs der Webseite mehrfach ab. Die Dauer der Aufrufe der Webseiten werden gemessen und
-statistisch ausgewertet. Für einen späteren Vergleich werden diese Informationen gesichert und mit einem erneuten Aufruf
-nach den Optimierungen verglichen. Hierdurch kann auch festgestellt werden, ob die Optimierungen erfolgreich waren.
-Um die Netzwerklatenz ignorieren zu können, wird das Skript auf dem gleichen Computer aufgerufen, auf dem die Webseite
-gestartet wurde.
+Damit die Messungen nachvollziehbar bleiben, werden die Testaufrufe durch ein Bash-Script automatisiert gerufen. 
+Wichtig hierbei ist, das die Webseite immer vollständig gerendert vom Server an den Client übertragen wird.
+Somit kann die clientseitige Performance ignoriert werden, da alles Daten direkt in dem einen Aufruf bereitgestellt
+wird. In dem Skript werden zum einen die Laufzeiten der Webanfragen ermittelt und die kürzeste, die längste und die
+durchschnittliche Laufzeit ermittelt. Aufgrund der Speicherprobleme, werden auch die Speicherbenutzung des
+\textit{Glassfish}"=Servers vor und nach den Aufrufen ermittelt. Zum Schluss werden noch die Log"=Dateien des 
+\textit{PostgreSQL}"=Servers über das Tool \textit{pgBadger} analysiert und als Bericht aufbereitet.
 
-Das zugehörige Script ist im Anhang \ref{ap:timing} angehängt.
+Um die Netzwerklatenz ignorieren zu können, wird das Skript auf dem gleichen Computer aufgerufen, auf dem der Webserver
+gestartet wurde. Das zugehörige Script ist im Anhang \ref{ap:timing} zu finden.