Daily CheckIn

This commit is contained in:
marcodn 2024-09-24 23:56:07 +02:00
parent 76f548484c
commit f2f1122846
6 changed files with 103 additions and 50 deletions

View file

@ -23,6 +23,7 @@
"SFSB", "SFSB",
"tabellenähnlichen", "tabellenähnlichen",
"unterlagerte", "unterlagerte",
"unterlagerten",
"vorverdichteten", "vorverdichteten",
"Wallstein" "Wallstein"
], ],

View file

@ -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

View file

@ -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

View file

@ -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.

View file

@ -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}

Binary file not shown.