Rechtschreibprüfung und Anpassung der Gliederung

chapters/expose/chapter01.tex

@@ -7,98 +7,161 @@ Die Editions- und Forschungsstelle Frank Wedekind (EFFW) wurde 1987 in der Hochs
 ist es, den lange vernachlässigten Autor der europäischen Moderne in die öffentliche Aufmerksamkeit zu bringen. Die 
 Publikation der >>Kritischen Studienausgabe der Werke Frank Wedekinds. Darmstädter Ausgabe<< im Verlag Jürgen Häuser
 wurde 1994 direkt nach der Erschließung der Wedekind-Nachlässe in Aarau, Lenzburg und München begonnen und im Jahre 
-2013 abgeschlossen (8 Bände in 15 Teilbänden, jetzt in Wallstein Verlag). Die EFFW wurde im Sommer 2015 an die 
+2013 abgeschlossen (8 Bände in 15 Teilbänden, jetzt in Wallstein Verlag). Die EFFW ist im Sommer 2015 an die 
 Johannes Gutenberg-Universität Mainz umgezogen.
 
-Da Frank Wedekind heute zu einem der bahnbrechenden Autoren der literarischen Moderne zählt, aber bisher sehr
+Da Frank Wedekind heute zu einen der bahnbrechenden Autoren der literarischen Moderne zählt, aber bisher sehr
-wenig erforscht wurde, soll sich diese nun Ändern. Die nationalen und internationalen Korrespondenzen von und an Wedekind
+wenig erforscht wurde, soll sich dies nun Ändern. Die nationalen und internationalen Korrespondenzen von und an Wedekind
 zeigen eine starke Vernetzung in der europäischen Avantgarde. Dies zeigt das die Wissenschaft um die Korrespondenzen
-von Wedekind eine immer größere Rolle spielen. Aktuell sind lediglich 710 der 3200 bekannten korrespondenzstücke
+von Wedekind eine immer größere Rolle spielen. Aktuell sind lediglich 710 der 3200 bekannten Korrespondenzstücke
 veröffentlicht worden.
 
-Um diese zu verändern entstand das Projekt >>Edition der Korrespondenz Frank Wedekind als Online-Volltextdatenk<< 
+Um jenes zu verändern entstand das Projekt >>Edition der Korrespondenz Frank Wedekind als Online-Volltextdatenbank<<
-\citep{EffwFrankWedekind}, welches bei der EFFW angesiedelt ist und als Kooperationsprojekt an der 
+\citep{EffwFrankWedekind}, welches bei der EFFW angesiedelt ist und als Kooperationsprojekt an der Johannes 
-Johannes Gutenberg-Universität Mainz, der Hochschule Darmstadt und der Fernuni Hagen umgesetzt wird und durch die
+Gutenberg-Universität Mainz, der Hochschule Darmstadt und der Fernuni Hagen umgesetzt und durch die Deutsch
-Deutsch Forschungsgemeinschaft (Bonn) gefördert wird.
+Forschungsgemeinschaft (Bonn) gefördert wird.
 
-Hierbei werden sämtliche bislang bekannten Korrespondenz in die Online-Edition überführt. Diese Korrespondenz
+Hierbei wurden sämtliche bislang bekannten Korrespondenzen in die Online-Edition überführt. Diese
-beinhaltet substantiell das literarhistorische und kulturgeschichtliche Wissen über die Kultur zwischen 1880 und 1918,
+beinhalteten substantiell das literarhistorische und kulturgeschichtliche Wissen über die Kultur zwischen 1880 und 1918,
-indem das überlieferte Material zum einen transkribiert editiert und editionswissenschaftlich kommentiert wird.
+indem das überlieferte Material zum einen transkribiert editiert und zum anderen editionswissenschaftlich kommentiert wurde.
-Und zusätzlich durch Kommentar die den historischen Kontexten inhaltlich erschließen.
+Inhaltlich erschlossen zusätzliche Kommentare den historischen Kontext.
 
 Hierfür entstand das Pilotprojekt der Online-Volltextdatenbank für Briefe von und an Frank Wedekind, welches 2015
-als Beta-Version freigeschalten wurde. Diese Projekt kann aktuell unter http://briefedition.wedekind.h-da.de eingesehen
+als Beta-Version freigeschalten wurde. Dieses Projekt kann aktuell unter http://briefedition.wedekind.h-da.de eingesehen
 werden.
 
 Die benutzerfreundliche Erfassung und Annotation der Briefe, ist eines der Hauptziele der konzeptionierten technischen
-Architektur. Die ist der Grund, warum die Präsentation-, Recherche- und Erstellungsebene vollständig webbasiert umgesetzt
+Architektur. Aus diesem Grund, wurde die Präsentation-, Recherche- und Erstellungsebene vollständig webbasiert umgesetzt.
-wurde. Die Briefe selbst, werden im etablierten TEI-Format gespeichert. Dies muss von den Editoren und Editorinnen nicht
+Die Briefe selbst, sind im etablierten TEI-Format gespeichert. Dies muss von den Editoren und Editorinnen nicht
-selbst eingegeben werden, sondern kann über einen entstanden WYSIWYG-Editor direkt eingegeben werden, welcher es bei
+selbst eingepflegt werden, sondern kann über einen entstanden WYSIWYG-Editor direkt eingegeben werden, welcher dies bei
-der Speicherung in das TEI-Format wandelt. Ebenfalls wurde hierbei auf eine modulare und unabhängige Architektur geachtet,
+der Speicherung in das TEI-Format umwandelt. Ebenfalls wurde hierbei auf eine modulare und unabhängige Architektur
-wodurch die Komponenten im Nachgang auch von anderen Briefeditionen genutzt werden können.
+geachtet, wodurch die Komponenten im Nachgang auch von anderen Briefeditionen genutzt werden können.
 
 \section{Ziel}
-% Anm: in dem Abschnitt vermischen Sie Ziele und Vorgehen
-Die aktuelle Umsetzung beinhaltet die bisher definierte Anforderungen komplett. Darunter fallen die Recherchemöglichkeiten,
-sowie auch die Eingabe und die Verarbeitung der Briefe. Ein größeres Problem hierbei ist die Performance der Oberfläche. 
-Durch die langen Abfragedauern des Datenbestandes leidet die Akzeptanz der Anwendung.
 
-Das Ziel der Arbeit ist es, die Abfragedauern zu verringern, wodurch die Performance der Oberfläche signifikant verbessert wird.
+Die aktuelle Umsetzung beinhaltet die bisher definierten Anforderungen vollständig, darunter fallen die 
-Anhand von Performance-Messungen und einer Befragung der Benutzer und Entwickler, werden die größten Performance-Probleme ermittelt und bewertet.
+Recherchemöglichkeiten, sowie auch die Eingabe und die Verarbeitung der Briefe. Ein größeres Problem hierbei ist die
-Anhand dieser Auswertungen ist dann das weitere vorgehen zu ermitteln.
+Performance der Oberfläche. Auf Grund der langen Abfragedauer des Datenbestandes leidet die Akzeptanz der Anwendung.
+
+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.
 
 \section{Aktueller Forschungsstand}
-% Anm: (dazu schreiben Sie gar nichts!) Genau das ist Ihre Aufgabe im Rahmen des Reading Courses die aktuelle Literatur - sei es in der Forschung, in Lehrbüchern, in
-% Systemliteratur etc. zum Thema Performance-Optimierung zu recherchieren, zu analysieren und den State of the Art zu beschreiben!
 
-Die Speicherveraltung des PostgreSQL-Server muss für Produktivsysteme angepasst werden \citep[34-38]{Eisentraut2013}. 
+Die Speicherverwaltung des PostgreSQL-Servers muss für Produktivsysteme angepasst werden \citep[34-38]{Eisentraut2013}. 
-Hierunter fallen die \textit{shared\_buffers} die bei ca. 10 bis 25 Prozent des verfügbaren Arbeitsspeichers liegen sollte, mit dieser Einstellung wird das häufige schreiben des Buffers durch Änderung von Daten und Indexen auf die Festplatte reduziert.
+Hierunter fallen die \textit{shared\_buffers} die bei ca. 10 bis 25 Prozent des verfügbaren Arbeitsspeichers liegen 
-Die Einstellung \textit{temp\_buffers} die definiert wie groß der Speicher für temporäre Tabellen pro Verbindung maximal werden darf, sollte ebenfalls überprüft werden, da ein zu kleiner Wert bei großen temporären Tabellen zu einem signifikanten Leistungseinbruch führt, wenn die Tabellen nicht im Hauptspeichern sondern in einer Datei bearbeitet werden.
+sollten. Mit dieser Einstellung wird das häufige Schreiben des Buffers durch Änderungen von Daten und Indexen auf die
-Der \textit{work\_mem} definiert die Obergrenze des zur Verfügung gestellt Hauptspeichers pro Datenbankoperation wie effizientes Sortieren, Verknüpfen oder Filtern. Auch wird im Falle eines zu klein gewählten Speichers auf temporäre Dateien auf der Festplatte ausgewichen, was ebenfalls zu signifikanten Leistungseinbrüchen führt.
+Festplatte reduziert. Die Einstellung \textit{temp\_buffers} definiert wie groß der Speicher für temporäre Tabellen pro
-Die \textit{maintenance\_work\_mem} wird bei Verwaltungsoperation wie Änderung und Erzeugung von Datenbankobjekten als Obergrenze definiert. Aber auch für die Wartungsaufgaben \texttt{Vacuum}, die fragmentierte Tabellen aufräumt und somit die performance hebt.
+Verbindung maximal werden darf und sollte ebenfalls überprüft werden. Ein zu kleiner Wert bei großen temporären Tabellen
+führt zu einem signifikanten Leistungseinbruch, wenn die Tabellen nicht im Hauptspeicher, sondern in einer Datei
+ausgelagert werden.
 
-Die Wartung des Datenbanksystems ist eine der wichtigen Aufgaben und sollte regelmässig durchgeführt werden, damit die Performance des Systems durch die Änderung des Datenbestandes nicht einbricht \citep[75]{Eisentraut2013}. Hierfür gibt es den \texttt{VACUUM}-Befehl, der entweder per Hand oder automatisch durch das Datenbanksystem ausgeführt werden soll.
+Der \textit{work\_mem} definiert die Obergrenze des zur Verfügung gestellt Hauptspeichers pro Datenbankoperation wie 
-Für die automatische Ausführung kann der maximal verwendete Speicher über die Einstellung \textit{autovacuum\_work\_mem} gesondert eingestellt werden \citep{PostgresPro:Chap20.4:2023}.
+effizientes Sortieren, Verknüpfen oder Filtern. Ebenso wird im Falle eines zu klein gewählten Speichers auf temporäre
-Neben dem aufräumen durch \texttt{VACUUM} sollten auch die Planerstatistiken mit \texttt{ANALYZE} \citep[83]{Eisentraut2013} aktuell gehalten werden. Damit die Anfragen durch den Planer richtig optimiert werden können. Für beide Wartungsaufgaben gibt es den Autovacuum-Dienst. Dieser sollte aktiv und richtig konfiguriert sein.
+Dateien auf der Festplatte ausgewichen, was signifikanten Leistungseinbrüchen zur Folge haben kann.
+Die \textit{maintenance\_work\_mem} wird bei Verwaltungsoperationen wie Änderungen und Erzeugungen von Datenbankobjekten
+als Obergrenze definiert. Die Wartungsaufgabe \texttt{VACUUM}, welche die fragmentierten Tabellen aufräumt und
+somit die Performance hebt, beachtet die Obergrenze ebenfalls.
 
-Mit dem Tool \textit{pgFouine} \citep[155]{Eisentraut2013} können die Logs des PostgreSQL Server analysiert werden und auf Probleme hin untersucht werden. Hiermit kann sehr einfach die häufigsten bzw. langsamsten Anfragen ermittelt werden.
+Die Wartung des Datenbanksystems ist eine der wichtigsten Aufgaben und sollte regelmäßig
+durchgeführt werden, damit die Performance des Systems durch die Änderungen des Datenbestands nicht einbricht
+\citep[75]{Eisentraut2013}. Hierfür gibt es den \texttt{VACUUM}-Befehl, welcher entweder per Hand oder automatisch durch
+das Datenbanksystem ausgeführt werden soll. Für die automatische Ausführung kann der maximal verwendete Speicher über
+die Einstellung \textit{autovacuum\_work\_mem} gesondert definiert werden \citep{PostgresPro:Chap20.4:2023}.
+Neben dem Aufräumen durch \texttt{VACUUM}, sollten auch die Planerstatistiken mit \texttt{ANALYZE}
+\citep[83]{Eisentraut2013} aktuell gehalten werden, damit die Anfragen durch den Planer richtig optimiert werden können.
+Für beide Wartungsaufgaben gibt es den Autovacuum-Dienst, dieser sollte aktiv und richtig konfiguriert sein.
 
-Für weitere Optimierungen müssen dann die Anfragen einzeln überprüft werden. Hierfür ist es sinnvoll die Ausführungspläne der Abfrage zu analysieren \citep[252]{Eisentraut2013}. Hierbei ist es wichtig die verschiedenen Plantypen und ihre Kosten zu kennen, sowie die angegeben Werte für die Plankosten zu verstehen \citep[24-30]{Dombrovskaya2021}. Hinzu kommt noch, dass man den tatsächlich ausgeführten Plan mit dem ursprünglichen Plan vergleichen sollte \citep[254]{Eisentraut2013}. Eine er wichtigsten Aussage hierbei ist, ob die Zeilenschätzung akkurat war. Größere Abweichung weißen häufig auf veraltete Statistiken hin.
+Mit dem Tool \textit{pgFouine} \citep[155]{Eisentraut2013} können die Logs des PostgreSQL Server analysiert und auf
-Um die Abfragen selbst zu optimieren gibt es ein Vorgehen über mehrere Schritte \citep[304-308]{Dombrovskaya2021}. Zuerst wird unterschieden ob es eine \textit{Kurze} oder eine \textit{Lange} Abfrage ist. Im Falle von einer Kurzen Abfrage werden zuerst die Abfragekriterien geprüft. Wenn dies nicht hilft, werden die Indexe geprüft. Sollte dies auch keine Verbesserung bringen, wird die Abfrage nochmal genauer analysiert und so umgestellt, dass die restriktivste Einschränkung zuerst zutrifft.
+Probleme hin untersucht werden. Hiermit können sehr einfach die häufigsten bzw. langsamsten Anfragen ermittelt werden.
-Bei Langen Abfragen sollte überprüft werden, ob es sinnvoll ist das Ergebnis in eine Tabelle zu speichern und bei Änderung zu aktualisieren. Wenn dies nicht möglich ist, sollten die nachfolgenden Schritte durchgeführt werden. Zuerst wird der restriktivste Join gesucht und geprüft ob dieser als ersten ausgeführt wird. Danach fügt man weitere Joins hinzu und prüft die Ausführungszeit und die Abfragepläne. Als nächstes wird geschaut, dass große Tabellen nicht mehrfach durchsucht werden. Bei Gruppierungen ist noch zu prüfen, ob diese früher durchgeführt werden können, ob die Abfragemenge zu verringern.
 
-Des Weiteren können über das Modul \texttt{pg\_stat\_statements} Statistiken über die Aufrufe die an den Server gestellt wurden, ermittelt werden \citep{PostgresF27:2023}. Hierbei kann ermittelt werden, welche der Anfragen am häufigsten gerufen werden und welche die längsten Laufzeiten besitzen.
+Für weitere Optimierungen sollen werden anschließend die Anfragen einzeln überprüft. Hierfür ist es sinnvoll die 
+Ausführungspläne der Abfrage zu analysieren \citep[252]{Eisentraut2013}, die verschiedenen Plantypen und ihre Kosten zu
+kennen, sowie die angegeben Werte für die Plankosten zu verstehen \citep[24-30]{Dombrovskaya2021}. 
+Besonderes Augenmerk gilt dem Vergleichen des tatsächlich ausgeführten mit dem ursprünglichen Plan
+\citep[254]{Eisentraut2013}. Eine der wichtigsten Kennzeichen hierbei ist, ob die Zeilenschätzung akkurat war,
+größere Abweichungen weißen häufig auf veraltete Statistiken hin.
+
+Um die Abfragen selbst zu optimieren, gibt es ein Vorgehen über mehrere Schritte \citep[304-308]{Dombrovskaya2021}.
+Zuerst wird Unterschieden, ob es sich um eine \textit{Kurze} oder eine \textit{Lange} Abfrage handelt. Im Falle einer
+\textit{Kurzen} Abfrage, werden zuerst die Abfragekriterien überprüft. Sollte dies zu keiner Verbesserung führen,
+werden die Indexe geprüft. Ist dies ebenso erfolglos, wird die Abfrage nochmals genauer analysiert und so
+umgestellt, dass die restriktivste Einschränkung zuerst zutrifft.
+Bei einer \textit{Langen} Abfrage soll überprüft werden, ob es sinnvoll ist, das Ergebnis in einer Tabelle zu
+speichern und bei Änderungen zu aktualisieren. Wenn dies nicht möglich ist, sollten die folgenden Schritte durchgeführt
+werden. Zuerst wird der restriktivste Join gesucht und überprüft, ob dieser als Erstes ausgeführt wird. Anschließend fügt
+man weitere Joins hinzu und prüft die Ausführungszeit und die Abfragepläne. Als Nächstes wird sich vergewissert, ob 
+große Tabellen nicht mehrfach durchsucht worden sind. Bei Gruppierungen ist noch zu prüfen, ob diese früher durchgeführt
+werden können, um die Abfragemenge zu verringern.
+
+Bei \textit{Langen} Abfragen ist die Abhandlung >>Optimizing Iceberg Queries with Complex Joins<<
+\citep{10.1145/3035918.3064053} ein zusätzlicher Ratgeber, um die Performance zu steigern.
+
+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.
 
 % MÜllerWehr2012
-Die \textit{Java Persistence API} (JPA) wird als First-Level-Cache in Java-EE-Anwendung gehandhabt. Hierbei nehmen die Objekte einen von 4 Zuständen ein \citep[57]{MüllerWehr2012}.
+Die \textit{Java Persistence API (JPA)} wird als First-Level-Cache in Java-EE-An\-wen\-dung verwendet, hier nehmen die
-Im \textit{Transient} sind die Objekt erzeugt, aber noch noch in den Cache überführt worden.
+Objekte einen von vier Zuständen ein \citep[57]{MüllerWehr2012}. Im Zustand \textit{Transient} sind die Objekt erzeugt,
-Wenn Sie in den Cache überführt werden, nehmen sie den Zustand \textit{Verwaltet} ein.
+aber noch nicht in den Cache überführt worden. Wenn diese in den Cache überführt worden sind, nehmen sie den Zustand
-Für das löschen eines Objektes gibt es den Zustand \textit{Gelöscht}, wodurch auch das Objekt aus der Datenbank entfernt wird.
+\textit{Verwaltet} ein. Ist das Objekt aus dem Cache und der Datenbank entfernt worden, nimmt es den Zustand
-Als letzten Zustand gibt es noch \textit{Losgelöst}, hierbei wird das Objekt aus dem Cache entfernt, aber nicht aus der Datenbank.
+\textit{Gelöscht} an. \textit{Losgelöst} ist der letzte Zustand, bei dem das Objekt aus dem Cache entfernt worden ist,
+aber nicht aus der Datenbank.
 
-Eine Menge von Objekten wird als \textit{Persistenzkontext}. Solange die Objekte dem Persistenzkontext zugeordnet sind, also den Zustand Verwaltet besitzen, werden diese auf Änderungen überwacht um diese am Abschluss mit der Datenbank zu synchronisieren. In der Literatur nennt man das \textit{Automatic Dirty Checking} \citep[61]{MüllerWehr2012}.
+Eine Menge von Objekten wird als \textit{Persistenzkontext} bezeichnet. Solange die Objekte dem
+\textit{Persistenzkontext} zugeordnet sind, also den Zustand \textit{Verwaltet} besitzen, werden diese auf Änderungen
+überwacht, um sie am Abschluss mit der Datenbank zu synchronisieren. In der Literatur wird hierzu der Begriff
+\textit{Automatic Dirty Checking} verwendet \citep[61]{MüllerWehr2012}.
 
-In den Java-EE-Anwendungen wird der Persistenzkontext für die Anfragen vom \textit{Application-Server} bereitgestellt. Hierfür werden Application-Server wie GlassFish genutzt, um die Verwendung eines Pools von Datenbankverbindungen zu definieren \citep[68]{MüllerWehr2012}.
+In den Java-EE-An\-wen\-dung\-en wird der \textit{Persistenzkontext} für die Anfragen vom \textit{Application-Server}
-Hiermit kann die Anzahl der Verbindung geringer gehalten werden als die Anzahl der Benutzer die an der Anwendung arbeiten.
+bereitgestellt. Hierfür werden \textit{Application-Server} wie \textit{GlassFish} genutzt, um die Verwendung eines Pools
-Zusätzlich werden die Transaktionen über Stateful Session-Bean (SFSB) gehandhabt, die automatisch vor dem Aufruf erzeugt und danach wieder gelöscht werden. Dies hat allerdings den Nachteil,
+von Datenbankverbindungen zu definieren \citep[68]{MüllerWehr2012}. Dadurch kann die Anzahl der Verbindung geringer
-dass der Persistenzkontext sehr groß werden kann, wenn viele Entities in den Persistenzkontext geladen werden. Da dies häufig zu Speicher- und damit Performanz-Problemen \citep[79]{MüllerWehr2012} führt, muss hier darauf geachtet werden, nicht mehr benötigte Entities aus dem Persistenzkontext zu lösen.
+gehalten werden als die Anzahl der Benutzer die an der Anwendung arbeiten. Zusätzlich werden die Transaktionen über
+\textit{Stateful Session-Bean (SFSB)} gehandhabt, welche automatisch vor dem Aufruf erzeugt und danach wieder gelöscht
+werden. Dies birgt allerdings den Nachteil, dass der \textit{Persistenzkontext} sehr groß werden kann, wenn viele
+Entities in den \textit{Persistenzkontext} geladen werden. Da dies häufig zu Speicher- und damit Performanz-Problemen
+\citep[79]{MüllerWehr2012} führen kann, muss hier darauf geachtet werden, nicht mehr benötigte Entities aus dem
+\textit{Persistenzkontext} zu lösen.
 
-Zusätzlich kann im JPA ebenfalls noch der \textit{Second Level Cache} (L2-Cache) aktiviert werden. Dieser Cache steht jedem Persistenzkontext zur Verfügung und kann dadurch die Anzahl der
+Zusätzlich kann im \textit{JPA} ebenfalls noch der \textit{Second Level Cache} (L2-Cache) aktiviert werden. Dieser steht
-Datenbankzugriffe deutlich reduzieren, was bei langsamen Datenbank-Anbindungen zu hohen Performance-Gewinnen führen kann \citep[171]{MüllerWehr2012}.
+jedem \textit{Persistenzkontext} zur Verfügung und kann dadurch die Anzahl der Datenbankzugriffe deutlich reduzieren,
-Entgegen der Verwendung spricht, dass die Daten im Second Level Cache explizit über Änderungen informiert werden müssen, sonst werden beim nächsten Laden wieder die alten Werte geliefert.
+was bei langsamen Datenbank-Anbindungen zu hohen Performance-Gewinnen führen kann \citep[171]{MüllerWehr2012}.
-Ebenfalls benötigt so ein Cache einen höheren Bedarf an Arbeitsspeicher, in diesem dann die Daten parallel zur Datenbank bereitgestellt werden.
+Gegen die Verwendung spricht, dass die Daten im \textit{Second Level Cache} explizit über Änderungen informiert werden
-Daher ist die Benutzung nur problemlos bei Entities, auf die meist lesend zugegriffen wird.
+müssen, welche sonst beim nächsten Aufruf veraltete Werte liefern. Ebenfalls benötigt so ein Cache einen höheren Bedarf
+an Arbeitsspeicher, in dem die Daten parallel zur Datenbank bereitgestellt werden, daher ist die Benutzung nur 
+problemlos bei Entities möglich, auf die meist lesend zugegriffen wird.
 
-In der OpenJPA-Erweiterung für den L2-Cache, wird in \textit{Objekt-Cache} (in OpenJPA als \textit{DataCache} bezeichnet) und Query-Cache unterschieden.
+In der OpenJPA-Erweiterung für den L2-Cache, wird in \textit{Objekt-Cache} (in OpenJPA als \textit{DataCache}
-Über die Funktionen \texttt{find()} und \texttt{refresh()} oder einer Query werden die geladenen Entities in den Cache gebracht. Davon ausgenommen sind \textit{Large Result Sets}
+bezeichnet) und Query-Cache unterschieden. Über die Funktionen \texttt{find()} und \texttt{refresh()} oder einer Query
-(Abfragen die nicht alle Daten auf einmal laden), \texttt{Extent}-Technologien und Queries, die einzelne Attribute von Entities zurückliefern, aber nicht das Entity selbst.
+werden die geladenen Entities in den Cache gebracht. Davon ausgenommen sind \textit{Large Result Sets} (Abfragen die
-Hierbei kann genau gesteuert werden, welche Entity in den Cache abgelegt wird und welche nicht. Ebenfalls kann auf Klassenbasis der zugehörige Cache definiert werden, um eine bessere Last-Verteilung beim Zugriff zu ermöglichen \citep[314]{MüllerWehr2012}.
+nicht alle Daten auf einmal laden), \texttt{Extent}-Technologien und Queries, die einzelne Attribute von Entities
+zurückliefern, aber nicht das Entity selbst. Hierbei kann genau gesteuert werden, welche Entity in den Cache abgelegt
+wird und welche nicht. Ebenfalls kann auf Klassenbasis der zugehörige Cache definiert werden, um eine bessere
+Last-Verteilung beim Zugriff zu ermöglichen \citep[314]{MüllerWehr2012}.
 
-Im Query-Cache werden die Abfragen bzw. die Eigenschaften einer Abfragen und die zurückgelieferten Ids der Entities gespeichert. Bei erneutem Aufruf dieser Abfrage werden die referenzierten Objekte aus dem Objekt-Cache zurückgegeben. Bei veränderten referenzierten Entities wird der Query-Cache nicht benutzt und die betroffenen Abfragen werden unverzüglich aus dem Query-Cache entfernt \citep[316]{MüllerWehr2012}.
+Im \textit{Query-Cache} werden die Abfragen bzw. die Eigenschaften einer Abfrage und die zurückgelieferten Ids der
+Entities gespeichert. Bei einen erneuten Aufruf dieser Abfrage werden die referenzierten Objekte aus dem
+\textit{Objekt-Cache} zurückgegeben. Bei veränderten referenzierten Entities wird der \textit{Query-Cache} nicht 
+genutzt und die betroffenen Abfragen werden unverzüglich aus dem \textit{Query-Cache} entfernt
+\citep[316]{MüllerWehr2012}.
 
-Um zu prüfen ob die Einstellungen sinnvoll gesetzt sind, gibt es in OpenJPA eine Cache-Statistik, die abgefragt werden kann. Mit dieser kann die Anzahl der Lese- und Schreibzugriffe im Cache überprüft werden. Entsprechend dieser Auswertung sollten die Einstellungen and den Entities angepasst werden \citep{IbmOpenJPACaching2023}.
+Um zu prüfen, ob die Einstellungen sinnvoll gesetzt sind, kann in OpenJPA eine Cache-Statistik abgefragt werden. Mit
+dieser kann die Anzahl der Lese- und Schreibzugriffe im Cache überprüft werden, entsprechend dieser Auswertung sollten
+die Einstellungen an den Entities angepasst werden \citep{IbmOpenJPACaching2023}.
+
+\section{Vorgehen bei der Umsetzung}
+
+Durch eine Umfrage der Bediener und Entwickler, einer Performance-Messung in der Webseite und den Statistiken im
+PostgreSQL, sollen die größten Performance-Probleme in der Webseite ermittelt und der dazugehörigen Quellcode
+identifiziert werden. Für die Analyse und Optimierung der Abfragen sollen verschiedene Blickwinkel betrachtet werden.
+
+Bei den einzelnen Abfragen muss zuerst ermittelt werden, in welchem Teil des Aufrufs die meiste Zeit aufgewendet wird,
+hierbei wird die Übertragung über das Netzwerk außer acht gelassen, da diese vom Standort und nicht direkt von der
+Anwendung abhängt. Ein geplantes Vorgehen ist hierbei die Überprüfung von >>unten nach oben<<, 
+wie in \ref{fig:webrequest} dargestellt.
 
 \begin{figure}
     \begin{tikzpicture}[node distance=5em,
@@ -133,20 +196,31 @@ Um zu prüfen ob die Einstellungen sinnvoll gesetzt sind, gibt es in OpenJPA ein
     
     \end{tikzpicture}
     \caption{Ablauf einer Web-Anfrage}
+    \label{fig:webrequest}
 \end{figure}
 
-% Zum ende noch, warum wird das gemacht? => Weil Datenbank-Definition immer unterschiedlich sind, und die Optimierung an den entsprechenden
+Zuerst soll der Aufruf gegen die Datenbank geprüft und die Ausführungszeit sowie die Abfragepläne ermittelt und
-% Datenbestand angepasst werden muss
+analysiert. Wenn sich hierbei größere Defizite erkennen lassen, werden die Abfragen direkt optimiert, indem der Aufbau
+der Abfrage, die Abfragekriterien und die Verwendung der Indexe betrachtet und in Frage gestellt werden.
 
-\section{Vorgehen bei der Umsetzung}
+Anschließend erfolgt die Prüfung des OpenJPA-Caches mit den zugehörigen Statistiken. Bei diesen wird einerseits ermittelt,
-% Anm: eine mögliche Vorgehensweise. Bei der Beschreibung der Vorgehensweise beziehen Sie sich dann natürlich auf den oben beschrieben Stand in Forschung und Technik
+wie sinnvoll der aktuelle Einsatz des Caches für die unterschiedlichen Entitäten ist und andererseits ob es sinnvoll ist
-Anhand der Umfrage der Bediener und Entwickler werden die größten Performance-Probleme in der Webseite ermittelt. Anhand dieser werden nun die dazugehörigen Quellcode identifiziert und analysiert. Hierbei müssen verschieden Blickwinkel betrachtet werden um die Performance zu optimieren.
+die aktuelle Nutzung zu minimieren oder ihn komplett zu entfernen. Ein Ersatz mit besserer Performance soll in diesem
+Fall ebenso untersucht werden.
 
-Darunter fallen zum einen die Cache-Algorithmen der JDBC-Engine, sowie auch die Einstellungen am Datenbanksystem. Hierbei ist noch ein besonderes Augenmerk auf die vorhandene Serverkonstellation mit zu beachteten, da diese enormen Einfluss auf die Einstellungen bewirkt. Ebenso werden die Aufrufe im ganzen überprüft und untersucht um zu prüfen ob die Anfragen sich gegenseitig durch Transaktionen oder Locks sperren. Hierfür wird ebenfalls die interne Protokollierung der Aufruf aktiviert und dessen Ausgabe untersucht und analysiert.
+Anschließend wird der Aufruf über die JPA betrachtet. Dies ist besonders wichtig, wenn
+die Abfragen dynamisch erzeugt werden und die SQL-Abfrage selbst nicht optimiert werden kann. In diesem Fall sollte
+nicht nur die reine Abfrage, sondern auch die Verwendung des Caches mit in Betracht gezogen werden.
 
-Danach werden die Abfrage selbst untersucht und auf Optimierungen überprüft. Hierbei wird als erstes der Aufruf der Abfrage betrachtet. Dann wird die Abfrage selbst genauer untersucht. Dabei wird beachtet ob die Anfragen selbst viel Zeit für die Bearbeitung benötigen oder auf Ressourcen warten. Zum anderen wid geprüft ob durch gezielte Umstellung oder Einfügen von Zwischenergebnissen schnellere Abfragen möglich sind, Wie es in der Abhandlung "Optimizing Iceberg Queries with Complex Joins" \cite{10.1145/3035918.3064053} gezeigt wird. Zum Schluss werden noch die Abfragekriterien und die vorhanden, beziehungsweise genutzten, Indizierungen überprüft.
+Nun wird die EJB-Schicht überprüft und die aufgerufen Funktionen betrachtet, ob hier einzelne Funktionen zu viele
+Aufgaben übernehmen und dadurch schlecht optimiert werden können. Solche Funktionen sollten dupliziert werden und auf
+die jeweilige Aufgabe spezifisch zugeschnitten und optimiert werden.
 
-Als letztes wird noch die Art des Aufrufers betrachtet. Hierbei wird die Art und Weise der Aufrufe genauer betrachtet. Ob zum Beispiel eine vorhandene Anfrage mehrfach verwendet wird und diese besser auf 2 ähnliche Abfrage aufgeteilt werden  kann. Oder ob an den Stellen ein Paging eingebaut werden kann, um die übertragene Datenmengen zu reduzieren.
+Abschließend ist die JSP-Schicht zu betrachten, welche noch logische Anpassungen für die Optimierungen zulässt,
-
+wie das Einfügen von Paging. Damit kann die ermittelnde Datenmenge verringert werden, dies führt zu schnelleren
-Zeitgleich wird der PostgreSQL sowie der Server selbst untersucht und die Einstellungen überprüft. Hierzu gehören die Größen der Speicher und die Wartungsaufgaben des Datenbanksystems. In diesem Zuge werden auch die Log-Dateien vom PostgreSQL, unter Zuhilfenahme von pgFouine, untersucht und auf Probleme und Unregelmässigkeiten geprüft.
+Abfragen, weniger Daten die im Cache vorgehalten werden müssen, den Aufbau der Seite zu beschleunigen und damit auch
+die Datenmenge die an den Browser übermittelt wird zu reduzieren.
 
+Zeitgleich werden der PostgreSQL sowie der Server selbst untersucht und die Einstellungen überprüft. Hierzu gehören die
+Größen der Speicher und die Wartungsaufgaben des Datenbanksystems. In diesem Zuge werden auch die Log-Dateien vom
+PostgreSQL, unter Zuhilfenahme von pgFouine untersucht und auf Probleme und Unregelmässigkeiten überprüft.

chapters/expose/chapter02.tex

@@ -7,26 +7,32 @@
     \item Einleitung
     \item Grundlagen % Technische Grundlagen erläutern
     \item Konzept % Konzept vorstellen und diskutieren, Alternativen abwägen usw.
-        %\begin{enumerate}
+        \begin{enumerate}
-        %    \item Beschreibung der aktuellen Webseite
+            \item Aufbau der Umfrage
-        %    \item Performanceanalyse
+            \item Allgemeine Betrachtung des Systems
-        %\end{enumerate}
+            \item Das Vorgehen der Optimierungen
+            \item Aktueller Aufbau der Software
+            \item Vergleich mit anderen Technologien
+        \end{enumerate}
     \item Performance-Untersuchung
         \begin{enumerate}
-            \item Befragung der Benutzer und Entwickler
+            \item Auswertung der Umfrage
+            \item Einbau und Aktivieren von Performance-Messung
+            \item Statistiken im PostgreSQL auswerten
             \item Überprüfung des PostgreSQL und Servers
-            \item Einbau und Aktivieren von Performancecounter
-            \item Laufzeitanalyse starten
         \end{enumerate}
         \item Optimierung
         \begin{enumerate}
+            \item Ermittlung der Performance-Probleme
+            \item Analyse der Abfragen
+            \item Optimierungen der Abfragen
             \item Anpassung der Konfiguration
-            \item Veränderung der Abfragen
-            \item Veränderung der Webseite
         \end{enumerate}
     \item Evaluierung
         \begin{enumerate}
+            \item Befragung der Benutzer und Entwickler
             \item Erneute Laufzeitanalyse starten
+            \item Statistiken im PostgreSQL auswerten
             \item Vergleich der Ergebnisse vor und nach der Optimierung
         \end{enumerate}
     \item Zusammenfassung und Ausblick

marco-galster-config.tex

@@ -7,7 +7,7 @@
 % ****************************************************************************************************
 % 1. Personal data and user ad-hoc commands
 % ****************************************************************************************************
-\newcommand{\myTitle}{Analyse und Optimierung der Datenbankabfragen der Webseite des Wedekind Projektes\xspace}
+\newcommand{\myTitle}{Analyse und Optimierung der Webseite des Wedekind Projektes\xspace}
 %\newcommand{\mySubtitle}{An Homage to The Elements of Typographic Style\xspace}
 \newcommand{\myDegree}{Bachelor of Science (B.Sc.)\xspace} 
 %\newcommand{\myDegree}{Bachelor of Arts (B.A.)\xspace}
@@ -59,4 +59,3 @@
 \definecolor{RoyalBlue}{cmyk}{1, 0.50, 0, 0}
 % \definecolor{Black}{cmyk}{0, 0, 0, 0}
 \definecolor{Black}{HTML}{221E1F} % Definition von https://en.wikibooks.org/wiki/LaTeX/Colors
-%\definecolor{black}{HTML}{221E1F}