Daily CheckIn
This commit is contained in:
parent
76f548484c
commit
f2f1122846
6 changed files with 103 additions and 50 deletions
1
.vscode/settings.json
vendored
1
.vscode/settings.json
vendored
|
@ -23,6 +23,7 @@
|
||||||
"SFSB",
|
"SFSB",
|
||||||
"tabellenähnlichen",
|
"tabellenähnlichen",
|
||||||
"unterlagerte",
|
"unterlagerte",
|
||||||
|
"unterlagerten",
|
||||||
"vorverdichteten",
|
"vorverdichteten",
|
||||||
"Wallstein"
|
"Wallstein"
|
||||||
],
|
],
|
||||||
|
|
|
@ -67,9 +67,8 @@ immer in einer chronologisch aufsteigenden Form zu darzustellen.
|
||||||
|
|
||||||
Aktuell verwenden die Editoren die Dokumentenliste um die Briefe eines Adressaten zu filtern und diese in
|
Aktuell verwenden die Editoren die Dokumentenliste um die Briefe eines Adressaten zu filtern und diese in
|
||||||
chronologische Reihenfolge aufzulisten und zu untersuchen wie Kommunikation zwischen Herrn Wedekind und dem Adressaten
|
chronologische Reihenfolge aufzulisten und zu untersuchen wie Kommunikation zwischen Herrn Wedekind und dem Adressaten
|
||||||
abgelaufen ist. Ebenso wird nach Standorten sortiert, um zu prüfen mit welchen Personen sich an den ...
|
abgelaufen ist. Ebenso wird nach Standorten sortiert, um zu ermitteln welchen Personen sich im Zeitraum am gleichen
|
||||||
|
Ort aufgehalten haben.
|
||||||
\mytodos{Hier noch mehr Infos dazu, für was genau die Editoren diese tun}
|
|
||||||
|
|
||||||
Da die Daten in der 3. Normalform in der Datenbank gespeichert werden, sind einige Relationen für die Abfragen
|
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 \ref{lst:documentlist} gezeigt. Zusätzlich wird für jedes
|
notwendig. Dies wird durch die generische Abfrage in \ref{lst:documentlist} gezeigt. Zusätzlich wird für jedes
|
||||||
|
|
|
@ -60,6 +60,18 @@ Dies wiederrum ist ein Vorteil für den Serverbetreiber, da durch die Verschiebu
|
||||||
benötigt wird. Gleichzeitig würde man wiederrum schwächere Clients, wie Smartphones, aussperren, da bei diesem
|
benötigt wird. Gleichzeitig würde man wiederrum schwächere Clients, wie Smartphones, aussperren, da bei diesem
|
||||||
die notwendige Rechenleistung fehlt, um die Webseite in annehmbarer Zeit darzustellen.
|
die notwendige Rechenleistung fehlt, um die Webseite in annehmbarer Zeit darzustellen.
|
||||||
|
|
||||||
|
\section{Serverseitige Paginierung}
|
||||||
|
\label{sec:evaluation:server-side-paging}
|
||||||
|
|
||||||
|
Die Aufteilung eines großen Datenbestandes in mehrere einzelne Seiten, ist eine der wenige Optimierungsmöglichkeiten in
|
||||||
|
der JSF"=Ebene. Dieser Einbau optimiert direkt an mehreren Stellen, dazu gehört die kleinere Datenmenge die vom
|
||||||
|
Datenbankserver geladen wird. Ebenso wird entsprechend weniger Zeit benötigt um die View zu erstellen und die zum
|
||||||
|
Client übertragene Datenmenge ist auch geringer. Dadurch benötigt die Seite auf dem Client auch weniger Zeit zum
|
||||||
|
rendern.
|
||||||
|
|
||||||
|
Da das Paging für den Fall der Dokumentenliste implementiert ist, gibt es hier keine weiteren offensichtliche
|
||||||
|
Optimierungsmöglichkeiten.
|
||||||
|
|
||||||
\section{Caching im OpenJPA}
|
\section{Caching im OpenJPA}
|
||||||
\label{sec:evaluation:caching-jpa}
|
\label{sec:evaluation:caching-jpa}
|
||||||
|
|
||||||
|
@ -183,6 +195,11 @@ verlagert wurde. Hiermit konnte zum einen Last vom Server genommen werden und di
|
||||||
optimieren. Die Wandlung der Daten in \textit{HTML}"=Objekte ist eine Kernkompetenz von JavaScript und damit auch bei
|
optimieren. Die Wandlung der Daten in \textit{HTML}"=Objekte ist eine Kernkompetenz von JavaScript und damit auch bei
|
||||||
schwächeren Clients in kurzer Zeit durchführbar.
|
schwächeren Clients in kurzer Zeit durchführbar.
|
||||||
|
|
||||||
|
Als weiteren Punkt ist anzumerken, das der Speicherbedarf des Webserver relativ konstant bleibt ohne das ein Cache
|
||||||
|
verwendet wird. Der größte Unterschied zur Standardimplementierung ist die Verwendung von eigenen Code um die Objekte
|
||||||
|
zu erstellen und zu befüllen und es nicht durch das OpenJPA"=Framework durchführen zu lassen.
|
||||||
|
Dies legt den Schluss nahe, dass es Probleme in der Speicherverwaltung der Objekte im OpenJPA"=Framework existieren.
|
||||||
|
|
||||||
Zusammenfassend ist zu sagen, dass die \textit{Materialized View} eine gute Wahl sind, um die Listendarstellungen
|
Zusammenfassend ist zu sagen, dass die \textit{Materialized View} eine gute Wahl sind, um die Listendarstellungen
|
||||||
zu optimieren. Mit dieser Technik können zum einen die Abfragezeiten optimiert werden, wodurch gleichzeit die
|
zu optimieren. Mit dieser Technik können zum einen die Abfragezeiten optimiert werden, wodurch gleichzeit die
|
||||||
Ressourcennutzung verringert wird. Zum anderen wird die Ressourcennutzung des Servers noch weiter reduziert, wenn die
|
Ressourcennutzung verringert wird. Zum anderen wird die Ressourcennutzung des Servers noch weiter reduziert, wenn die
|
||||||
|
|
|
@ -3,47 +3,84 @@
|
||||||
\chapter{Zusammenfassung und Ausblick}
|
\chapter{Zusammenfassung und Ausblick}
|
||||||
\label{ch:summary_and_outlook}
|
\label{ch:summary_and_outlook}
|
||||||
|
|
||||||
\mytodos{hier eine kurze Zusammenfassung über 2-3 Seiten}
|
\mytodos{die 2 Untersektionen beibehalten?}
|
||||||
|
|
||||||
\iffalse
|
\section{Zusammenfassung}
|
||||||
% umstellung auf matview sinnvoll bei verwendung von joins
|
\label{sec:Summary_and_outlook:results}
|
||||||
% bei joins von 1:n ist die Wandlung über json sinnvoll, aber parsen erst am client
|
% In der Gegenwart schreiben, außer bei verweisen auf die Arbeit, dann in der Vergangenheit!
|
||||||
|
|
||||||
!!! Hier nochmal die Nutzerumfrage mit einbringen
|
Die Untersuchungen am Beispiel des Wedekind"=Projektes zeigen, dass mehrere Optimierungsmöglichkeiten in den
|
||||||
|
Briefedition existieren. Für die Untersuchung wurde sich auf die Dokumentenliste beschränkt und anhand dieser
|
||||||
|
die Optimierung implementiert, untersucht und jeweils mit der Ausgangsmessung vergleichen. Für die Messung wurden
|
||||||
|
Skripte erstellt, die auf dem gleichen Computer wie der Webserver und der Datenbankserver laufen, damit diese auch
|
||||||
|
vergleichbar bleiben und externe Einflussfaktoren minimiert werden.
|
||||||
|
|
||||||
- Einführung in die Ergebnisse
|
\mytodos{den Absatz hier drin lassen oder raus?}
|
||||||
- Darstellung der Kernergebnisse
|
%Messung zeigt wo die probleme liegen! hier noch ausformulieren
|
||||||
- Analyse und Interpretation
|
Durch die Ausgangsmessungen war erkennbar, dass der größte Teil der Verarbeitungszeit im bereitstellen der Entitäten
|
||||||
- Einordnung in den Forschungskontext
|
benötigt wird. Die Messung der Abfragen auf der Datenbank wiederum konnte die hohe Verarbeitungszeit nicht bestätigen,
|
||||||
- Zusammenfassung und Übergang zur Diskussion
|
daher lag hier schon die Vermutung nahe, dass der Großteil der Zeit im ORM"=Mapper verloren geht.
|
||||||
|
|
||||||
Du beginnst mit einer präzisen Beschreibung deiner Untersuchung, um ein klares Verständnis der Grundlagen zu schaffen,
|
Die Methode der Nutzerumfrage wurde nicht weiterverfolgt, da diese aufgrund zu wenigen Bedienern nicht zielführend war.
|
||||||
und hebst spezifische Daten sowie Analysemethoden hervor (1).
|
Bei der Untersuchung der Datenbank, wurde festgestellt, dass die Struktur aktuell für die Anwendung optimal ist und
|
||||||
|
daher eine Restrukturierung keine Vorteile entstehen lässt. Die statische Webseite und die komplett Client basierte
|
||||||
|
Webseite wurde auf Grund von technischen Einschränkungen nicht weiterverfolgt.
|
||||||
|
|
||||||
Anschließend präsentierst du die Kernergebnisse deiner Forschung klar und strukturiert, fokussierst dabei auf
|
Bei den Caches sind der Query"=Cache und der EJB"=Cache nicht für die Optimierung verwendbar. Der Query"=Cache wird
|
||||||
relevante Entdeckungen, die direkt zur Beantwortung deiner Forschungsfrage beitragen (2).
|
von OpenJPA nur verwendet, wenn die Abfragen keine Parameter besitzt, welche in der Dokumentliste verwendet werden
|
||||||
|
mussten. Im EJB"=Cache werden nicht die Objekt, sondern die Provider gespeichert, wodurch hier keine Auswirkung auf die
|
||||||
|
Performance festgestellt werden konnte.
|
||||||
|
|
||||||
Eine tiefgehende Analyse folgt, in der du die Daten nicht nur beschreibst, sondern auch im Kontext der theoretischen
|
Anders sieht es bei dem OpenJPA"=Cache aus, dieser hat direkten Einfluss auf die Performance der Ermittlung der Daten
|
||||||
Grundlagen interpretierst und untersuchst, wie sie deine Hypothesen unterstützen oder herausfordern (3).
|
und Bereitstellung der dazugehörigen Java"=Objekte. Anhand der vorgegeben Cache"=Größe kann das Potential der
|
||||||
|
Optimierung eingestellt werden. Dies bedeutet, soweit der Cache groß genug ist um alle notwendigen Objekte zu
|
||||||
|
speichern, sind die Verbesserung gut messbar. Ab dem Zeitpunkt, dass Objekte aus dem Cache entfernt werden müssen,
|
||||||
|
wird die Optimierung immer geringer.
|
||||||
|
|
||||||
Die Ergebnisse setzt du dann in den breiteren akademischen und praktischen Forschungskontext und diskutierst ihren
|
Ein sehr ähnliches Verhalten konnte mit dem Ehcache festgestellt werden, nur dass bei diesem die Limitierungen höher
|
||||||
Beitrag zu bestehenden Theorien sowie die sich eröffnenden neuen Perspektiven (4).
|
angesetzt sind und die Verwaltung des Caches im Gesamtsystem effizienter aufgebaut ist, als bei OpenJPA.
|
||||||
|
|
||||||
Abschließend fasst du die wichtigsten Erkenntnisse zusammen und schaffst einen nahtlosen Übergang zur Diskussion,
|
In beiden Fällen der Optimierung über die Nutzung eines Caches, konnte durch die Messungen in der Software und der
|
||||||
indem du betonst, wie deine Ergebnisse die ursprünglichen Fragestellungen untersucht haben und welche Folgen sich für
|
Abfragen an der Datenbank nachgewiesen werden, dass nicht das Ermitteln der Daten die größte Zeit einnimmt, sondern
|
||||||
weiterführende Forschungen ergeben könnten (5).
|
das Erstellen und Befüllen der Objekte in Java.
|
||||||
\fi
|
|
||||||
|
|
||||||
Das Ziel dieser Bachelorarbeit war es, durch die Untersuchung der Schichten am Beispiel des Wedekind"=Projektes
|
Bei dem Vergleich der unterschiedlichen Abfragemethoden Criteria API und JPQL konnte keine Unterschied in der
|
||||||
Optimierungsmöglichkeiten zu finden. Für die Untersuchung wurde sich auf die Dokumentenliste beschränkt und anhand
|
Performance und Abarbeitung festgestellt werden. Bei beiden Methoden konnte nachgewiesen werden, dass die syntaktisch
|
||||||
dieser die Optimierungen implementiert, untersucht und jeweils mit dem Ausgangspunkt verglichen.
|
gleichen Abfragen an die Datenbank gestellt wurden. Bei den Abfragen zur Dokumentenliste konnten in beiden Fällen
|
||||||
Hierzu wurde der Aufbau der Software in seine unterschiedlichen Schichten zerlegt und diese einzeln Untersucht.
|
durch die Umstellung der Ermittlung der unterlagerten Daten durch Hints eine Optimierung erreicht werden. Die Umstellung
|
||||||
Für jede Schicht wurde
|
bezweckt das die unterlagerten Daten nicht einzeln für jede Zeile ermittelt wurde, sondern alle Daten auf einmal
|
||||||
Bei den Schichten
|
geladen werden und die Zuordnung der Datensätze im OpenJPA"=Framework durchgeführt wird.
|
||||||
wurde, zu diesen zählen
|
|
||||||
die Enterprise Java Beans, die Java Persistance API, die OpenJPA,
|
|
||||||
|
|
||||||
|
Mit der übernahme der \textit{Materialized View} aus dem Wedekind"=Projekt konnte erstmalig ein gute Optimierung
|
||||||
|
beobachtet werden. Dies ist auf die einfachere Abfrage, die Reduzierung der Abfrage an den Datenbankserver und das
|
||||||
|
die Objekte in eigenen Code erstellt werden und nicht durch das OpenJPA"=Framework. Hierbei konnte noch nachgewiesen
|
||||||
|
werden, dass das parsen der Json"=Daten, die die unterlagerten Objekte enthalten, den größten Teil der Zeit benötigen.
|
||||||
|
Auf Grund dessen wurde das parsen der Json"=Daten auf den Client verschoben, was zu einem noch besseren Ergebnis führte.
|
||||||
|
|
||||||
Für dieses Ziel wurde sich auf die Dokumentenliste beschränkt und diese jeweils
|
Für die Optimierung der Abfragen wurde die Hauptabfrage betrachtet. Bei dieser konnte anhand der visuell Darstellung
|
||||||
für die unterschiedllichen Optimierungen angepasst.
|
das Problem gut identifiziert werden. Durch die Verwendung einer \textit{Common Table Expression} wurde die Anzahl
|
||||||
Es wurde
|
der Datensatze direkt am Anfang auf die angefragte Menge reduziert, wodurch die Anzahl der zu betrachteten Datensätze
|
||||||
|
für die weiteren Verlinkungen enorm reduziert wurden. Somit konnte der Datenbankserver bei diesen Verlinkung auf Indexe
|
||||||
|
zugreifen und damit die Abfragen zusätzlich beschleunigen.
|
||||||
|
|
||||||
|
Die Untersuchungen zeigen, dass mehrere Möglichkeiten zur Optimierung existierten, um die Zugriffe auf die
|
||||||
|
Briefeditionen zu beschleunigen und das das größte Optimierungspotential in den ORM"=Mapper vorhanden ist. Welche der
|
||||||
|
Optimierungen verwendet werden, liegt zum einen an der Komplexität der Abfrage und der bereitgestellten Ressourcen
|
||||||
|
des Servers.
|
||||||
|
|
||||||
|
\section{Ausblick}
|
||||||
|
\label{sec:summary_and_outlook:outlook}
|
||||||
|
|
||||||
|
Die Untersuchungen zeigen, dass die Schichten über OpenJPA weitestgehend optimal umgesetzt sind, beziehungsweise wenig
|
||||||
|
Möglichkeiten für eine Optimierungen zu lassen. Einzig das parsen von Json ist in einem Webbrowser schneller als im
|
||||||
|
Server durchführbar. Auf diese Weise könnten zusätzlich die Ressourcen am Server reduziert werden, beziehungsweise mit
|
||||||
|
gleichen Ressourcen mehr Anfragen als bisher beantwortet werden.
|
||||||
|
|
||||||
|
Die größten Optimierungspotentiale könne durch Umstellung der Abfragen und der Optimierung des ORM"=Mappers umgesetzt
|
||||||
|
werden. Bei den Umstellungen der Abfragen ist größte Stärke, wenn die Anzahl der Abfragen drastisch reduziert werden
|
||||||
|
können.
|
||||||
|
|
||||||
|
Dadurch zeigt sich, dass die Untersuchung auf Ebene der ORM"=Mapper noch nicht abgeschlossen ist. Weitere Untersuchungen
|
||||||
|
nach anderen ORM"=Mapper könnten wie in \ref{sec:evaluation:materialized-view} angedeutet das Speicherproblem lösen,
|
||||||
|
sowie eine generelle Optimierung der Webseite zur Folge haben. Eine eigenständige Implementierung eines einfachen
|
||||||
|
ORM"=Mapper wäre auch in Betracht zu ziehen, solange sich die Komplexität der Daten"=Struktur nicht erhöht.
|
|
@ -4,19 +4,18 @@
|
||||||
\begin{otherlanguage}{ngerman}
|
\begin{otherlanguage}{ngerman}
|
||||||
\pdfbookmark[0]{Zusammenfassung}{Zusammenfassung}
|
\pdfbookmark[0]{Zusammenfassung}{Zusammenfassung}
|
||||||
\chapter*{Zusammenfassung}
|
\chapter*{Zusammenfassung}
|
||||||
\mytodos{Dies am Ende noch Ausfüllen!!!}
|
Die Briefedition des Wedekind"=Projektes stellt die Korrespondenz von Frank Wedekind als Online"=Volltextdatenbank
|
||||||
|
zur Verfügung um die Forschung an Frank Wedekind zu fokussieren. Um die Akzeptanz der Webseite zu erhöhen, damit
|
||||||
|
weitere Forscher sich mit dem Thema beschäftigen, soll die Reaktionszeit für die Anfragen reduziert werden.
|
||||||
|
|
||||||
Kurze Zusammenfassung des Inhaltes in deutscher Sprache von ca. einer Seite länge. Dabei sollte vor allem auf die folgenden Punkte eingegangen werden:
|
Diese Arbeit betrachtet die verschiedenen Layer der Anwendung und die jeweiligen Optimierungsmöglichkeiten. Hierbei
|
||||||
\begin{itemize}
|
wird ein rein technischer Ansatz gewählt, der durch Skript basierte Messungen überprüft und ausgewertet wird.
|
||||||
\item Motivation: Wieso ist diese Arbeit entstanden? Warum ist das Thema der Arbeit (für die Allgemeinheit) interessant? Dabei sollte die Motivation von der konkreten Aufgabenstellung, z.B. durch eine Firma, weitestgehend abstrahiert werden.
|
Betrachtet werden hierbei die Auswirkungen der verschiedenen Caches, die Abfragesprachen, eine Umstellung der
|
||||||
\item Inhalt: Was ist Inhalt der Arbeit? Was genau wird in der Arbeit behandelt? Hier sollte kurz auf Methodik und Arbeitsweise eingegangen werden.
|
Abfragen auf \textit{Materialized Views} und die Optimierungsmöglichkeiten der Abfragen.
|
||||||
\item Ergebnisse: Was sind die Ergebnisse der Arbeit? Ein kurzer Überblick über die wichtigsten Ergebnisse als Teaser, um die Arbeit vollständig zu lesen.
|
|
||||||
\end{itemize}
|
|
||||||
\medskip
|
|
||||||
|
|
||||||
\noindent
|
Es zeigt sich, dass die Ebenen unterschiedlich gute Optimierungsmöglichkeiten besitzen und die Caches die einfachste
|
||||||
Eine großartige Anleitung von Kent Beck, wie man gute Abstracts schreibt, finden Sie hier:
|
Art der Optimierung sind, stattdessen benötigen diese zusätzliche Ressourcen im Sinne des Arbeitsspeichers.
|
||||||
\begin{center}
|
Die Umstellung der \textit{Materialized View} inklusive der Zusammenfassung der unterlagerten Daten in eine Zeile
|
||||||
\url{https://plg.uwaterloo.ca/~migod/research/beckOOPSLA.html}
|
zeigt das größte Optimierungspotential. Durch die Umstellung der Abfragen kann ebenfalls die Verarbeitungszeit
|
||||||
\end{center}
|
reduziert werden, ist durch den größeren Anteil des ORM"=Mapper aber nicht stark ausschlaggebend.
|
||||||
\end{otherlanguage}
|
\end{otherlanguage}
|
||||||
|
|
BIN
thesis.pdf
BIN
thesis.pdf
Binary file not shown.
Loading…
Reference in a new issue