Dialy CheckIn

This commit is contained in:
marcodn 2024-09-03 23:48:35 +02:00
parent 8e6f13b64c
commit 40014ecaae
4 changed files with 51 additions and 42 deletions

View file

@ -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.

View file

@ -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.

View file

@ -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.

Binary file not shown.