bachelor-thesis/chapters/thesis/chapter03.tex

% !TeX root = ../../thesis.tex

\chapter{Konzept}
\label{ch:concept}

Das folgende Kapitel enthält die im Rahmen dieser Arbeit entstandenen Konzepte, um die vorhandenen Probleme zu
identifizieren und mit entsprechenden Maßnahmen entgegenzusteuern. Hierbei werden zum einen die Konfigurationen
der eingesetzten Software überprüft. Zum anderen werden die verschiedenen Schichten der entwickelten Software
auf mögliche Optimierungen untersucht und bewertet.

\section{Allgemeine Betrachtung des Systems}
\label{sec:concept:viewsystem}

Für die Untersuchung des Systems wird der direkte Zugang zum Server benötigt. Hierbei werden zuerst die im 
\autoref{sec:basics:services} beschriebenen Einstellungen überprüft.

Zuerst wird am PostgreSQL"=Server die Konfiguration der Speicher mit der Vorgabe für Produktivsysteme abgeglichen.
Hierunter fallen die Einstellungen für die \texttt{shared\_buffers}, der bei einem Arbeitsspeicher von mehr als 1 GB
circa 25\% des Arbeitsspeichers besitzen sollte \cite{PostgresC20.4:2024}.

Bei der Einstellung \texttt{temp\_buffers} geht es um den Zwischenspeicher für jede Verbindung, die bei der Verwendung
von temporären Tabellen verwendet wird. Dieser Wert sollte auf dem Standardwert von 8 MB belassen werden und lediglich 
bei der Verwendung von großen temporären Tabellen verändert werden.

Der Speicher, der für eine Abfrage verwendet werden darf, wird über die Konfiguration \texttt{work\_mem} gesteuert.
Wenn der Speicher zu gering wird, werden die Zwischenergebnisse in temporäre Dateien ausgelagert. Der empfohlene Wert
berechnet sich aus \texttt{shared""\_buffers} dividiert durch \texttt{max\_connections} \citep{ConfigTo12:online}.
Sollte die Berechnung außerhalb der Grenzwerte von 1 MB und 256 MB liegen, ist der jeweilige Grenzwert zu verwenden.
Um zu ermitteln, ob die Konfiguration richtig ist, muss im PostgreSQL die Einstellung \texttt{log\_""temp\_""files} auf 0
gesetzt werden. Mit dieser wird ermittelt, ob temporäre Dateien verwendet werden sowie deren Größe. Bei vielen kleineren
Dateien sollte der Grenzwert erhöht werden. Bei wenigen großen Dateien ist es ist sinnvoll den Wert so zu belassen.

Für die Wartungsaufgaben wie VACUUM oder dem Erstellen von Indexen wird die Begrenzung über die Einstellung
\texttt{maintenance\_work\_mem} gesetzt. Dieser Wert sollte 5\% des verfügbaren Arbeitsspeicher entsprechen und größer
als \texttt{work\_mem} sein.

Nachfolgend wird mit den Systemtools, wie den Konsolenanwendungen \textit{htop} und \textit{free}, die Auslastung des Servers 
überprüft. Hierbei ist die CPU"=Leistung, der aktuell genutzte Arbeitsspeicher, sowie die Zugriffe auf die Festplatte
die wichtigsten Faktoren zur Bewertung.

Die CPU"=Leistung sollte im Schnitt 70\% nicht überschreiten, für kurze Spitzen wäre dies zulässig, um die gestellten
Anfragen schnell genug abarbeiten zu können. Daher soll verhindert werden, dass der Server an seiner Leistungsgrenze 
arbeitet.

Da unter Linux der Arbeitsspeicher nicht mehr direkt freigegeben wird, ist hier die Page"=Datei der wichtigere Indikator.
Wenn dieses in Verwendung ist, dann benötigen die aktuell laufenden Programme mehr Arbeitsspeicher als vorhanden ist,
wodurch der aktuell nicht verwendete in die Page"=Datei ausgelagert wird. Zu beachten ist hierbei allerdings, dass sich 
die Zugriffszeiten auf die Elemente drastisch erhöhen.

Die Zugriffsgeschwindigkeit, die Zugriffszeit sowie die Warteschlange an der Festplatte zeigt deren Belastungsgrenze auf.
In diesem Fall kann es mehrere Faktoren geben. Zum einem führt das Paging des Arbeitsspeicher zu erhöhten Zugriffen. 
Ein zu klein gewählter Cache oder gar zu wenig Arbeitsspeicher erhöhen die Zugriffe auf die Festplatte, da weniger
zwischengespeichert werden kann und daher diese Daten immer wieder direkt von der Festplatte geladen werden müssen.

\section{Untersuchung der Anwendung}
\label{sec:concept:softwarestructure}

Bei der Performance"=Untersuchung der Anwendung wird sich im ersten Schritt auf die Dokumentenliste beschränkt. Anhand
dieser können die Optimierungen getestet und überprüft werden. Im Nachgang können die daraus gewonnenen Kenntnisse auf
die anderen Abfragen übertragen werden.

Die Dokumentenliste zeigt direkte und indirekte Informationen zu einem Dokument an. Hierzu gehört die Kennung des
Dokumentes, das Schreibdatum, der Autor, der Adressat, der Schreibort und die Korrespondenzform. Nach jeder dieser
Informationen kann der Bediener die Liste auf"= oder absteigend sortieren lassen. Zusätzlich wird die Liste immer nach 
dem Schreibdatum sortiert, um die Ergebnisse bei gleichen Werten der zu sortierenden Informationen, wie dem Schreibort,
immer in einer chronologisch aufsteigenden Form darzustellen.

Aktuell verwenden die Editoren die Dokumentenliste, um die Briefe eines Adressaten zu filtern und diese in
chronologische Reihenfolge aufzulisten und zu untersuchen, wie die Kommunikation zwischen Herrn Wedekind und dem Adressaten
abgelaufen ist. Ebenso wird nach Standorten sortiert, um zu ermitteln, welche Personen sich in einem Zeitraum am gleichen
Ort aufgehalten haben.

Da die Daten in der 3. Normalform in der Datenbank gespeichert werden, sind einige Relationen für die Abfragen
notwendig. Dies wird durch die generische Abfrage in \autoref{lst:documentlist} gezeigt. Zusätzlich wird für jedes
dargestellte Dokument eine zusätzliche Abfrage durchgeführt, wie in \autoref{lst:documentlist_sub} zeigt, dass auch hier
weitere Relationen notwendig sind.

\includecode[SQL]{chapters/thesis/chapter03_documentlist.sql}{lst:documentlist}{Generische Abfrage der Dokumentenliste}
\includecode[SQL]{chapters/thesis/chapter03_documentlist_sub.sql}{lst:documentlist_sub}{Sub-Abfrage pro Dokument}

Nach aktuellem Stand beinhaltet die Datenbank circa 5400 Briefe, für die jeweils zwei bis sieben eingescannte Faksimile
gespeichert werden. Diese Graphik"=Dateien werden im TIFF"=Format abgespeichert und benötigen zwischen 1 und 80 MB
Speicherplatz. Dadurch kommt die Datenbank aktuell auf circa 3,8 GB.

Wie in \autoref{ch:basics} dargestellt, besteht die eigentliche Anwendung aus mehreren Schichten. Die
PostgreSQL"=Schicht wurde schon im vorherigen Kapitel betrachtet. Daher werden nun die weiteren Schichten des 
GlassFish"=Servers in aufsteigender Reihenfolge betrachtet.

Die OpenJPA Cache Schicht wird nun einzeln untersucht. Hierfür werden 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 wird 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 werden und die Statistik"=Webseite um diese Daten erweitern. Um die Daten zu ermitteln, kann der
Quellcode aus \ref{lst:persistence-context-statistics} verwendet werden.

\begin{lstlisting}[language=Java,caption={Persistence"=Kontext Statistik},label=lst:persistence-context-statistics]
EntityManagerFactory emf = Persistence.createEntityManagerFactory(...);
EntityManager em = emf.createEntityManager();
for(EntityType<?> entityType : em.getMetaModel().getEntities()) 
{
    Class<?> managedClass = entityType.getBindableJavaType();
    System.out.println("Managing type: " + managedClass.getCanonicalName());
}

// Oder bei JPA 2.0
emf.getCache().print();
\end{lstlisting}

Die Schicht \ac{EJB} besitzt keine Möglichkeit, um eine sinnvolle Messung durchzuführen, daher wird hierfür keine
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 einfügt, wofür eine \textit{Factory} benötigt wird. Diese wird in den Pipeline
Prozess, der die Verarbeitung der Seiten steuert, eingebunden und erstellt die Klasse für die Messung.
In dieser werden die Zeiten zum Ermitteln der Daten, das Zusammensetzen und das Rendern 
der Sicht ermittelt. Die Zeiten werden in die Log"=Datei des \textit{GlassFish}"=Servers hinterlegt und durch das 
Skript ausgewertet. Somit ist es relativ leicht aufzuzeigen, an welcher Stelle die größte 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. Zum anderen werden die Abfragen durch Criteria API erzeugt
und dessen Ausführungszeit ermittelt.

Zusätzlich werden im PostgreSQL"=Server Optimierungen vorgenommen, darunter zählen die \textit{Materialized View}, welche eine 
erweiterte Sicht ist. Neben der Abfrage der Daten beinhalteten diese auch vorberechnete Daten der Abfrage, womit 
diese viel schneller abgefragt werden können. Zusätzlich werden die \textit{Cached queries} überprüft, ob diese eine Verbesserung 
der Performance ergeben und damit eine Reduzierung der Abfragedauern erreichen.

Damit die Messungen nachvollziehbar bleiben, werden die Testaufrufe durch ein Bash"=Script automatisiert gerufen. 
Wichtig hierbei ist, dass die Webseite immer vollständig gerendert vom Server an den Client übertragen wird.
Somit kann die clientseitige Performance ignoriert werden, da alle Daten bereits direkt in diesem einem Aufruf bereitgestellt
werden. In dem Skript werden zum einen die Laufzeiten der Webanfragen ermittelt, zum anderen die kürzeste, die längste und die
durchschnittliche Laufzeit ermittelt. Auf Grund der Speicherprobleme wird 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.

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 in \autoref{ap:timing} zu finden.