mdn/bachelor-thesis
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Aktuelle Forschung - vorerst fertig + Spellchecking

Browse source
This commit is contained in:
marcodn 2024-01-04 14:59:23 +01:00
parent 58c4b9ab6a
commit b1d10b2eef
4 changed files with 78 additions and 127 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

174
chapters/expose/chapter01.tex
View file

@ -6,22 +6,22 @@
Die Editions- und Forschungsstelle Frank Wedekind (EFFW) wurde 1987 in der Hochschule Darmstadt gegründet. Ihr Intention
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 Aurau, Lenzburg und München begonnnen und im Jahre
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
Johannes Gutenberg-Universitt Mainz umgezogen.
Johannes Gutenberg-Universität Mainz umgezogen.
Da Frank Wedekind heute zu einem der bahnbrechendenen Autoren der literarischen Moderne zählt, aber bisher sehr
wenig erforscht wurde, soll sich diese nun Ändern. Die nationalen und internalen Korrespondenzen von und an Wedekind
zeigen eine starke Vernetzung in der europäischen Avantgard. Dies zeigt das die Wssenschaft um die Korresponedenzen
Da Frank Wedekind heute zu einem 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
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
veröffentlich worden.
veröffentlicht worden.
Um diese zu verändern entstand das Projekt >>Edition der Korrespondenz Frank Wedekind als Online-Volltextdatenk<< \citep{EffwFrankWedekind},
welches bei der EFFW angesiedelt ist und als Kooperationsprojekt an der Johannes Gutenberg-Universität Mainz, der
Hochschule Darmstadt und der Fernuni Hagen umgesetzt wird und durch die Deutsch Forschungsgemeinschaft (Bonn)
gefördert wird.
Um diese zu verändern entstand das Projekt >>Edition der Korrespondenz Frank Wedekind als Online-Volltextdatenk<<
\citep{EffwFrankWedekind}, welches bei der EFFW angesiedelt ist und als Kooperationsprojekt an der
Johannes Gutenberg-Universität Mainz, der Hochschule Darmstadt und der Fernuni Hagen umgesetzt wird und durch die
Deutsch Forschungsgemeinschaft (Bonn) gefördert wird.
Hierbei werden sämtliche bislang bekanten Korrespondenz in die Online-Edition überführt. Diese Korrespondenz
Hierbei werden sämtliche bislang bekannten Korrespondenz in die Online-Edition überführt. Diese Korrespondenz
beinhaltet 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.
Und zusätzlich durch Kommentar die den historischen Kontexten inhaltlich erschließen.
@ -32,20 +32,20 @@ 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
wurde. Die Briefe selbst, werden im etablierten TEI-Format gespeichert. Dies muss von den Editoren und Editorienen nichst
selbst eingegeben werden, sondern kann über einen entstandenn WYSIWYG-Editor direkt eingegebenw werden, welcher es bei
wurde. Die Briefe selbst, werden 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
der Speicherung in das TEI-Format wandelt. Ebenfalls wurde hierbei auf eine modulare und unabhängige Architektur 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 aktzeptanz der Anwendung.
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. Anhand der Quellen müssen hierfür die Abfragen ermittelt und bewertet werden. Die Abfragen mit den höchsten
Zeitbedarf werden dann analysiert und optimiert.
Das Ziel der Arbeit ist es, die Abfragedauern zu verringern, wodurch die Performance der Oberfläche signifikant verbessert wird.
Anhand von Performance-Messungen und einer Befragung der Benutzer und Entwickler, werden die größten Performance-Probleme ermittelt und bewertet.
Anhand dieser Auswertungen ist dann das weitere vorgehen zu ermitteln.
Hierbei ist auch ein Vergleich mit anderen Technologien angedacht.
@ -54,99 +54,51 @@ Hierbei ist auch ein Vergleich mit anderen Technologien angedacht.
% 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}.
Hierunter fallen die \textbf{shared\_buffers} die bei
ca. 10 bis 25 Prozent des verfügbaren Arbeitsspeichers liegen sollte, mit dieser wird das häufige schreiben des Buffers durch Änderung
von Daten und Indexen auf die Festplatte reduziert.
Die Einstellung \textbf{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 beareitet werden.
Der \textbf{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 signifikaten Leistungsinbrüchen führt.
Die \textbf{maintenance\_work\_mem} wird bei Verwaltungsoperation wie Änderung und Erzeugung von Datenbankobjekten als Obergrenze definiert.
Aber auch für die Wartungsaufgaben \textbf{Vacuum}, die fragmentierte Tabellen aufräumt und somit die performance hebt. Welche Regelmässig
durchgeführt werden sollte.
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.
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.
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.
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.
Die Wartung des Datenbanksystemes 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 \textbf{VACUUM}-Befehl, der
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 \textbf{autovacuum\_work\_mem} gesondert
eingestellt werden \citep{PostgresPro:Chap20.4:2023}.
Neben dem aufräumen durch \textbf{VACUUM} sollten auch die Planerstatistiken mit \textbf{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.
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.
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}.
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.
Mit dem Tool \textbf{pgFouine} \citep[155]{Eisentraut2013} können die Logs des PostgreeSQL Server im Nachgang analysiert werden und auf
Probleme hin untersucht werden. Hiermit kann sehr einfach die häufigsten bzw. langsamsten Anfragen ermittelt werden.
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.
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. 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.
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.
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.
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.
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.
% MÜllerWehr2012
Die 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}.
Im \textbf{Transient} sind die Objekt erzeugt, aber noch noch in den Cache überführt worden.
Wenn Sie in den Cache überführt wwerden, nehmen sie den Zustand \textbf{Verwaltet} ein.
Für das löschen eines Objektes gibt es den Zustand \textbf{Gelöscht}, wodurch auch das Objekt
aus der Datenbank entfernt wird.
Als letzten Zustand gibt es noch \textbf{Losgelöst}, hierbei wird das Objekt aus dem Cache
entfernt, aber nicht aus der Datenbank.
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}.
Im \textit{Transient} sind die Objekt erzeugt, aber noch noch in den Cache überführt worden.
Wenn Sie in den Cache überführt werden, nehmen sie den Zustand \textit{Verwaltet} ein.
Für das löschen eines Objektes gibt es den Zustand \textit{Gelöscht}, wodurch auch das Objekt aus der Datenbank entfernt wird.
Als letzten Zustand gibt es noch \textit{Losgelöst}, hierbei wird das Objekt aus dem Cache entfernt, aber nicht aus der Datenbank.
Eine Menge von Objekten wird als \textit{Persistenzkontext}. Solange die Objkte dem Persistenzkontext
zugeordnet sind, also den Zustand Verwaltet besitzen, werden diese auf Änderungen überwucht
um diese am Abschluss mit der Datenbank zu syncronisieren. In der Literatur nennt man das
\textit{Automatic Dirty Checking} \citep[61]{MüllerWehr2012}.
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}.
In den Java-EE-Anwendungen wird der Persistenzkontext für die Anfragen vom Application-Server
bereitgestellt. Hierfür werden Application-Server wie GlassFish\textbf{!!!URL!!!} genutzt,
um die Verwendung eines Pools von Datenbankverbindungen zu definieren \citep[68]{MüllerWehr2012}.
Hiermit kann die Anzahl der Verbindung geringer gehalten werden als die Anzahl der Benutzer die
an der Anwendung arbeiten.
Zusätzlich werden die Transaktionen über Stateful Session-Bean (SFSB) gehandbabt, die automatisch
vor dem Aufruf erzeugt und danach wieder gelöscht werden. Dies hat allerdings den Nachteil,
dass der Persistenzkontext sehr groß werden kann, wenn viele Entities in den Persistenzkontext
geladen werden. Da dies häufig zu Speicher- und damit Performan-Problemen \citep[79]{MüllerWehr2012}
führt, muss hier darauf geachtet werden, nicht mehr benötigte Entities aus dem Persistenzkontext
lösen, oder den Transaktionskontext aufzuteilen \citep[172]{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}.
Hiermit kann die Anzahl der Verbindung geringer gehalten werden als die Anzahl der Benutzer die an der Anwendung arbeiten.
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,
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.
Zusätzlich kann hier 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
Datenbankzugriffe deutlich reduzieren, was bei langsamen Datenbank-Anbindungen zu hohen
Performance-Gewinnen führen kann \citep[171]{MüllerWehr2012}.
Engegen 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.
Ebenfalls benötigt so ein Cache einen höheren Bedarf an Arbeitsspeicher, in diesem dann die
Daten parallel zur Datenbank bereitgestellt werden.
Daher ist die Benutzung nur problemlos bei Entities, auf die meist lesend zugeriffen werden.
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
Datenbankzugriffe deutlich reduzieren, was bei langsamen Datenbank-Anbindungen zu hohen Performance-Gewinnen führen kann \citep[171]{MüllerWehr2012}.
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.
Ebenfalls benötigt so ein Cache einen höheren Bedarf an Arbeitsspeicher, in diesem dann die Daten parallel zur Datenbank bereitgestellt werden.
Daher ist die Benutzung nur problemlos bei Entities, auf die meist lesend zugegriffen wird.
In der OpenJPA-Erweiterung für den Second Level Cache, wird in Objekt-Cache
(in OpenJPA als \textit{DataCache} bezeichnet) und Query-Cache unterschieden.
Über die Funktionen \texttt{find()} und \texttt{refresh()} oder einer Query werden die
geladenen Entities in den Cache gebracht. Davon ausgenommen sind \textit{Larg Result Sets}
(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.
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}.
In der OpenJPA-Erweiterung für den L2-Cache, wird in \textit{Objekt-Cache} (in OpenJPA als \textit{DataCache} bezeichnet) und Query-Cache unterschieden.
Ü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}
(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.
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 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}.
Um zu prüfen ob die Einstellungen sinnvoll gesetzt sind, gibt es eine Cache-Statistik.
Mit diesen kann überprüft werden, wieviel Lese- und Schreibzugriffe im Cache durchgeführt wurden,
Entsprechend dieser Auswertung sollten die Einstellungen angepasst werden \citep{IbmOpenJPACaching2023}.
% Konversationen (Aufteilung von Transaktion, Seite 172)
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}.
% Zum ende noch, warum wird das gemacht? => Weil Datenbank-Definition immer unterschiedlich sind, und die Optimierung an den entsprechenden
@ -154,24 +106,12 @@ Entsprechend dieser Auswertung sollten die Einstellungen angepasst werden \citep
\section{Vorgehen bei der Umsetzung}
% 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
Zuerst werden alle Abfragen ermittelt und deren Performance in Abhängigkeit der Häufigkeit der Aufrufe und Datenmengen
bestimmt. In der Auflistung werden dann die 5-7 Anfragen bestimmt, bei dennen die größten Performance-Optimierungen möglich
ist. Diese Abfragen werden dann genauer untersucht. Hierbei werden verschiedene Blickwinkel betrachtet um die Performance
zu optimieren.
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.
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 Protokolierung der Aufruf aktiviert
und dessen Ausgabe untersucht und analysiert.
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.
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 Afragekriterien
und die vorhanden, beziehungsweise genutzen, Indizierungen überprüft.
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.
Als letztes wird noch die Art des Aufrufes 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 Datenmengen zu reduzieren.
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.
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.

9
chapters/expose/chapter02.tex
View file

@ -13,10 +13,10 @@
%\end{enumerate}
\item Performance-Untersuchung
\begin{enumerate}
\item Einbau von Performancecounter
\item Aktivieren von Performancecounter am Postgresql
\item Laufzeitanalyse starten
\item Befragung der Benutzer und Entwickler
\item Überprüfung des PostgreSQL und Servers
\item Einbau und Aktivieren von Performancecounter
\item Laufzeitanalyse starten
\end{enumerate}
\item Optimierung
\begin{enumerate}
@ -29,6 +29,5 @@
\item Erneute Laufzeitanalyse starten
\item Vergleich der Ergebnisse vor und nach der Optimierung
\end{enumerate}
\item Zusammenfassung
\item Ausblick
\item Zusammenfassung und Ausblick
\end{enumerate}

22
expose-ref.bib
View file

@ -46,7 +46,7 @@
year = 2023,
url = {https://www.postgresql.org/docs/8.4/pgstatstatements.html},
urldate = {2023-12-27}
}
},
% File: 978-1-4842-3546-1.pdf
@BOOK{Sharan2018,
@ -79,7 +79,7 @@
ISBN = {978-1-4842-8991-4},
PUBLISHER = {Apress Berkeley, CA},
ADDRESS = {New York},
}
},
% File: fröhlich-2022-postgresql.pdf / Ehemalinger Link: doi:10.3139/9783446473157
@book{Fröhlich2022,
@ -92,7 +92,7 @@
edition = {},
URL = {https://www.hanser-elibrary.com/doi/abs/10.3139/9783446473157},
eprint = {https://www.hanser-elibrary.com/doi/pdf/10.3139/9783446473157}
}
},
% Buch PostgreSQL - Administration (Hagen Leihe)
@book{Eisentraut2013,
@ -103,7 +103,7 @@
ISBN = {978-3-868-99362-2},
PUBLISHER = {O'Reilly Germany},
ADDRESS = {Köln},
}
},
% File: müller-wehr-2012-java-persistence-api-2.pdf / Ehemaliger Link: doi:10.3139/9783446431294
@book{MüllerWehr2012,
@ -116,7 +116,19 @@
edition = {},
URL = {https://www.hanser-elibrary.com/doi/abs/10.3139/9783446431294},
eprint = {https://www.hanser-elibrary.com/doi/pdf/10.3139/9783446431294}
}
},
@book{Dombrovskaya2021,
author = {Dombrovskaya, Henrietta AND Novikov, Boris AND Bailliekova, Anna},
year = {2021},
doi = {10.1007/978-1-4842-6885-8},
title = {PostgreSQL Query Optimization - The Ultimate Guide to Building Efficient Queries},
isbn = {978-1-4842-6885-8},
publisher = {Apress},
address = {Berkeley, CA},
url = {https://link.springer.com/book/10.1007/978-1-4842-6885-8},
eprint = {https://link.springer.com/book/10.1007/978-1-4842-6885-8}
},
% noch offen:
% - OpenJPA: https://openjpa.apache.org/documentation.html

BIN
expose.pdf
View file

Binary file not shown.