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

Rechtschreibkorrektur Präsentation

Browse source
This commit is contained in:
marcodn 2024-11-03 14:36:50 +01:00
parent df7042b4b7
commit d1e074858c
2 changed files with 18 additions and 18 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

BIN
thesis-beamer.pdf
View file

Binary file not shown.

36
thesis-beamer.tex
View file

@ -88,8 +88,8 @@
\column{.5\textwidth}
\begin{itemize}
\item Eine webbasierte Anwendung der Frank Wedekind Briefedition
\item Performance Problem bei der Abfrage der Briefe sowie der Recherchen der Korrespondenzen
\item entsprechend geringere Akzeptanz der Anwendung
\item Performance Probleme bei der Abfrage der Briefe sowie der Recherchen der Korrespondenzen
\item Entsprechend geringere Akzeptanz der Anwendung
\end{itemize}
\end{columns}
\end{frame}
@ -219,7 +219,7 @@
\begin{itemize}
\item Verwendung von Docker, zur Performance"=Limitierung
\item Eigene Container für die Datenbank und den Webserver
\item Für die Untersuchung wird nur die Dokumentenliste beobachtet
\item Für die Untersuchung wird lediglich die Dokumentenliste beobachtet
\item Verwendung von Scripts zur besseren Vergleichbarkeit und Wiederholgenauigkeit
\end{itemize}
\end{frame}
@ -228,15 +228,15 @@
\frametitle{Vorgehen}
\begin{itemize}
\item Vor jeder Messung werden die Container neugestartet und die Startroutinen abgewartet
\item Aufruf eines Bash"=Script auf dem gleichen Rechner wie die Docker-Container um die Latenz des Netzwerkes auszuschließen
\item Ermittlung des Speicherbedarfs vor und nach dem Webseitenaufrufen
\item Aufruf eines Bash"=Script auf dem gleichen Rechner wie die Docker-Container, um die Latenz des Netzwerkes auszuschließen
\item Ermittlung des Speicherbedarfs vor und nach dem Aufrufen der Webseiten
\item Messung der Aufruf der Index"=Seite (ohne Datenbankaufrufe) und der Dokumentenliste, jeweils 10 mal
\item Report über die SQL"=Abfragen mit pgBadger erstellen
\end{itemize}
\end{frame}
\begin{frame}[c]
\frametitle{Erste Auffäligkeiten}
\frametitle{Erste Auffälligkeiten}
\begin{itemize}
\item OutOfMemory"=Ausnahme ausgelöst nach dem vierten Script Aufruf ($\sim$40 Webseitenaufrufe)
\item Erhöhung des Java"=Heapspeichers von 512MB auf 4096MB hat nur die Anzahl der Aufrufe bis zum Absturz verzögert
@ -296,8 +296,8 @@
\begin{itemize}
\item Konfiguration über die Webseite des Payara"=Servers
\item habt keine Auswirkungen auf die Performance
\item Der Cache wird nur von den Provider selbst und nicht den geladenen Datenbank"=Objekten verwendet
\item Hat keine Auswirkungen auf die Performance
\item Der Cache wird nur von den Providern selbst und nicht den geladenen Datenbank"=Objekten verwendet
\end{itemize}
\vspace{8pt}
@ -311,16 +311,16 @@
\begin{itemize}
\item Ähnliche gemessene Zeiten
\item Untersuchung im Debugger zeigt ähnlicher Abfrage"=Syntax innerhalb von OpenJPA
\item Untersuchung im Debugger zeigt ähnlichen Abfrage"=Syntax innerhalb von OpenJPA
\item Prüfung der SQL"=Abfragen zeigt, dass die identischen Befehle an die Datenbank übertragen werden
\item Keine Unterschied im Speicherverbrauch feststellbar
\item Kein Unterschied im Speicherverbrauch feststellbar
\item Gleiche Optimierung durch Hint \texttt{openjpa.FetchPlan.EagerFetchMode} (halbierte Laufzeit, geviertelte Datenbankaufrufe)
\item Andere Hints hatte keine messbaren Auswirkungen
\item Andere Hints hatten keine messbaren Auswirkungen
\end{itemize}
\vspace{8pt}
\begin{corollary}
Daher kann die Art der Programmierung verwendet werden die für den Anwendungsfall die einfachere ist
Daher kann die Art der Programmierung verwendet werden, die für den Anwendungsfall die einfachere ist
\end{corollary}
\end{frame}
@ -433,7 +433,7 @@
\onslide<2>
\begin{itemize}
\item Erwartete Reduzierung der Datenbankabfragen
\item Laufzeit der Datenbankabfragen halbiert sich nur trotz signifikant weniger Abfragen
\item Laufzeit der Datenbankabfragen halbiert sich nur, trotz signifikant weniger Abfragen
\item Starke Reduzierung der Laderoutine von Datenbank nach Java"=Objekten
\item Geringer Speicheranstieg trotz des Caches
\item Sehr effizienter Cache, auch bei größeren Datenmengen
@ -493,7 +493,7 @@
\onslide<1>
\begin{itemize}
\item Materialized View und Webseite aus dem aktuellen Wedekind"=Projekt übernommen \citep{Dokument53:online}
\item Zusätzliche Anpassung an der View um die Parameter in der Abfrage zu entfernen für Test mit QueryCache
\item Zusätzliche Anpassung an der View, um die Parameter in der Abfrage zu entfernen für Test mit QueryCache
\item Verschiebung des JSON"=Parsen in den Webclient
\end{itemize}
@ -501,7 +501,7 @@
\begin{itemize}
\item Deutliche Reduzierung der Datenbankabfragen und "=laufzeiten
\item Unter"=Abfragen werden als JSON"=Objekte direkt hinterlegt
\item Teuer beim erstellen, aber selten notwendig
\item Teuer beim Erstellen, aber selten notwendig
\item Geringe Schwankung der Aufrufzeiten
\item Anteil der Datenbank nochmals reduziert
\item Deutliche Reduzierung der DB"=Load Laufzeit durch Verschiebung des JSON"=Parsing
@ -565,7 +565,7 @@
\begin{overprint}
\onslide<1>
\begin{itemize}
\item Große Datenmenge vom ersten Befehlt bis fast zur Ausgabe
\item Große Datenmenge vom ersten Befehl bis fast zur Ausgabe
\item Höchste Kosten im Seq Scan der Dokumententabelle
\item Nur Seq Scan bei den verlinkten Tabellen
\item Am Ende ist ein teurer Sort notwendig
@ -576,9 +576,9 @@
\item Umstellung mit dem WITH"=Statement
\item Große Datenmenge verschwindet nach dem ersten Hash join
\item Verwendung von Index Scan
\item Kosten der Sortierung am Ende reduziert
\item Reduktion der Kosten der Sortierung am Ende
\item Reduktion der Laufzeit um den Faktor drei
\item Nur möglich wenn die Bedingen ins WITH eingetragen werden können
\item Nur möglich, wenn die Bedingungen ins WITH eingetragen werden können
\end{itemize}
\end{overprint}