Current CheckIn
This commit is contained in:
parent
a1829bfcfc
commit
f7f27842ff
7 changed files with 105 additions and 52 deletions
3
.vscode/settings.json
vendored
3
.vscode/settings.json
vendored
|
@ -14,6 +14,7 @@
|
|||
"Plantypen",
|
||||
"SFSB",
|
||||
"unterlagerte",
|
||||
"Wallstein"
|
||||
"Wallstein",
|
||||
"xsep"
|
||||
],
|
||||
}
|
|
@ -8,22 +8,50 @@ die Reaktionszeit der Software ein sehr wichtiges Kriterium. Hierfür muss siche
|
|||
werden, dass die Anwendung immer in kurzer Zeit reagiert oder entsprechende Anzeigen dargestellt
|
||||
um eine längere Bearbeitung anzuzeigen.
|
||||
|
||||
\section{Motivation}
|
||||
\label{sec:intro:motivation}
|
||||
%\section{Motivation}
|
||||
%\label{sec:intro:motivation}
|
||||
|
||||
Die Frank"=Wedekind"=Bibliothek soll als Grundlage weiterer Forschungen dienen. Durch die weitere Forschung soll die
|
||||
literarhistorische und kulturgeschichtliche Wissen über die Kultur zwischen 1880 und 1918 erweitern. Um dieses
|
||||
Vorhaben umsetzen zu können muss die Anwendung dem Benutzer gerecht werden, damit diese verwendet wird und somit
|
||||
den Wissenstand entsprechend erweitert werden kann.
|
||||
%Die Frank"=Wedekind"=Bibliothek soll als Grundlage weiterer Forschungen dienen. Durch die weitere Forschung soll die
|
||||
%literarhistorische und kulturgeschichtliche Wissen über die Kultur zwischen 1880 und 1918 erweitern. Um dieses
|
||||
%Vorhaben umsetzen zu können muss die Anwendung dem Benutzer gerecht werden, damit diese verwendet wird und somit
|
||||
%den Wissenstand entsprechend erweitert werden kann.
|
||||
|
||||
Um das Ziel der Akzeptanz zu erreichen und das sich die Bediener rein auf ihre Arbeit konzentrieren können, muss mit der
|
||||
Anwendung flüssig interagiert werden können. Entsprechend müssen die Wartzeiten auf ein minimum reduziert werden.
|
||||
Des Weiteren muss die Stabilität der Anwendung gesteigert werden.
|
||||
%Um das Ziel der Akzeptanz zu erreichen und das sich die Bediener rein auf ihre Arbeit konzentrieren können, muss mit der
|
||||
%Anwendung flüssig interagiert werden können. Entsprechend müssen die Wartzeiten auf ein minimum reduziert werden.
|
||||
%Des Weiteren muss die Stabilität der Anwendung gesteigert werden.
|
||||
|
||||
\section{Ausgangslage}
|
||||
\label{sec:intro:initial-situation}
|
||||
|
||||
\mytodos{hier die Grundlagen aus dem Expose? Braucht man die Motivation dann noch?}
|
||||
Die Grundlage zu dieser Arbeit bildet das DFG-Projekt "Edition der Korrespondenz Frank Wedekinds als Online"=Volltextdatenbank".
|
||||
Die folgende Übersicht hierzu ist eine Anlehnung an \citep{EffwFrankWedekind}.
|
||||
|
||||
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<<
|
||||
wurde direkt nach der Erschließung der Wedekind-Nachlässe in Aarau, Lenzburg und München begonnen und im Jahre
|
||||
2013 abgeschlossen.
|
||||
|
||||
Da der 1864 geborene Frank Wedekind heute zu einen der bahnbrechenden Autoren der literarischen Moderne zählt, aber bisher sehr
|
||||
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. Aktuell sind lediglich 710 der 3200 bekannten Korrespondenzstücke
|
||||
veröffentlicht worden.
|
||||
|
||||
Diese beinhalten substantiell das literarhistorische und kulturgeschichtliche Wissen über die Kultur zwischen 1880
|
||||
und 1918, indem das überlieferte Material zum einen transkribiert editiert und zum anderen editionswissenschaftlich
|
||||
kommentiert wurde.
|
||||
|
||||
Um jenes zu verändern entstand das Projekt >>Edition der Korrespondenz Frank Wedekind als Online"=Volltextdatenbank<<,
|
||||
welches bei der EFFW angesiedelt ist und als Kooperationsprojekt an der Johannes Gutenberg"=Universität Mainz,
|
||||
der Hochschule Darmstadt und der Fernuni Hagen umgesetzt und durch die Deutsch Forschungsgemeinschaft (Bonn) gefördert wird.
|
||||
|
||||
Das entstandene Pilotprojekt ist eine webbasiert Anwendung, die aktuell unter \url{http://briefedition.wedekind.h-da.de}
|
||||
eingesehen werden kann. Hierbei wurden sämtliche bislang bekannte Korrespondenzen in dem System digitalisiert. Die
|
||||
Briefe selbst werden im etablierten TEI-Format gespeichert und über einen WYSIWYG-Editor von den Editoren und
|
||||
Editorinnen eingegeben.
|
||||
|
||||
Das Projekte wurde anhand von bekannten und etablierten Entwurfsmustern umgesetzt um eine modulare und unabhängige
|
||||
Architektur zu gewährleisten, damit dies für weitere digitale Briefeditionen genutzt werden kann.
|
||||
|
||||
\section{Ziel der Arbeit}
|
||||
\label{sec:intro:goal}
|
||||
|
|
|
@ -2,11 +2,16 @@
|
|||
\chapter{Konzept}
|
||||
\label{ch:concept}
|
||||
|
||||
Das folgende Kapitel enthält die im Rahmen dieser Arbeit entstandenen Konzepte, um die aktuellen Probleme aufzuzeigen.
|
||||
Hierbei sind verschiedene Vorgehen zu verwenden, da die Anwendung aktuell noch nicht als produktive Anwendung
|
||||
freigegeben ist. Zum einen werden die aktuelle Mitarbeiter befragt, zu anderen wird der Produktionsserver selbst
|
||||
überprüft. Danach wird die Anwendung an sich untersucht und zum Schluss wird eine Neuentwicklung mit Hilfe anderer
|
||||
Frameworks diskutiert.
|
||||
|
||||
\section{Aufbau der Umfrage}
|
||||
\label{sec:concept:poll}
|
||||
|
||||
|
||||
Die Umfrage wird über Email an die XX Personen verschickt. Als Basis für die Umfrage wird der aktuelle Prototyp
|
||||
Die Umfrage wird per Email an die XX Personen verschickt. Als Basis für die Umfrage wird der aktuelle Prototyp
|
||||
unter \href{https://briefedition.wedekind.h-da.de} verwendet. Hierbei wird die gleiche Umfrage für Bearbeiter
|
||||
und Benutzer versendet.
|
||||
|
||||
|
@ -23,7 +28,6 @@ Die Anfrage wird im Anhang \ref{ch:Umfrage} dargestellt.
|
|||
\section{Allgemeine Betrachtung des Systems}
|
||||
\label{sec:concept:viewsystem}
|
||||
|
||||
% Untersuchung des Servers
|
||||
Für die Untersuchung des Systems wird der direkte Zugang zum Server benötigt. Hierbei werden zuerst die im Kapitel
|
||||
\ref{sec:basics:services} beschriebenen Einstellungen überprüft.
|
||||
|
||||
|
@ -42,32 +46,31 @@ Server an seiner Leistungsgrenze arbeitet und dadurch es nicht mehr schafft die
|
|||
abzuarbeiten.
|
||||
|
||||
Da unter Linux der Arbeitsspeicher nicht mehr direkt freigegeben wird, ist hier die Page-Datei der wichtigere Indikator.
|
||||
Wenn dieses in Verwendung ist, dann benötigt die aktuell laufenden Programme mehr Arbeitsspeicher als vorhanden, wodurch
|
||||
der aktuell nicht verwendete in die Page-Datei ausgelagert wird. Hierdurch erhöhen sich die Zugriffszeiten auf diese
|
||||
Elemente drastisch.
|
||||
Wenn dieses in Verwendung ist, dann benötigt die aktuell laufenden Programme mehr Arbeitsspeicher als vorhanden ist,
|
||||
wodurch der aktuell nicht verwendete in die Page-Datei ausgelagert wird. Hierdurch erhöhen sich die Zugriffszeiten auf
|
||||
diese Elemente drastisch.
|
||||
|
||||
Die Zugriffsgeschwindigkeit, die Zugriffszeit sowie die Warteschlange an der Festplatte zeigt deren Belastungsgrenze auf.
|
||||
Hierbei kann es mehrere Faktoren geben. Zum einem führt das Paging des Arbeitsspeicher zu erhöhten Zugriffen. Ein zu
|
||||
klein gewählter Cache oder gar zu wenig Arbeitsspeicher erhöhen die Zugriffe auf die Festplatte, da weniger
|
||||
zwischengespeichert werden kann und daher diese Daten immer wieder direkt von der Festplatte geladen werden müssen.
|
||||
|
||||
\mytodos{Bespreibung der untersuchung von Glassfisch? oder lieber später}
|
||||
\section{Untersuchung der Anwendung}
|
||||
\label{sec:concept:softwarestructure}
|
||||
|
||||
\section{Das Vorgehen der Optimierung}
|
||||
\label{sec:concept:optimizing}
|
||||
Wie im Kapitel \ref{ch:basics} dargestellt, besteht die eigentliche Anwendung aus mehreren Schichten. Hierbei ist jede
|
||||
Schicht einzeln aber auch im ganze zu betrachten.
|
||||
|
||||
\mytodos{Beschreibung der Untersuchung von Glassfisch? oder lieber später, oder doch eher umbennen in Ermittlung der Performance-Probleme}
|
||||
\mytodos{angenfangen bei jeder Schicht, kurz beschreiben und was da getan wird um dort etws zu untersuchen}
|
||||
|
||||
\mytodos{Zum enden dann den gesammten Server untersucht, durch automatisiert Test über shell-Skripte die jede Seite mehrfach
|
||||
aufrufen und die Messung dazu protokolieren sowie die min und max werte (Skript als Listening in den Anhang?)}
|
||||
|
||||
% Anhand der Umfragen werden die verschiedenen Seiten ermittelt und mit den Tools überprüft
|
||||
% Während dessen kann über ein Script die Seite automatisiert abgefragt und das Trace aktiv sind
|
||||
% je nach erkentnis mss dann der Lösungsweg beschritten werden
|
||||
% je nach Erkenntnis muss dann der Lösungsweg beschritten werden
|
||||
% Beachten des Speicherverbrauchs!
|
||||
|
||||
\section{Aktueller Aufbau der Software}
|
||||
\label{sec:concept:softwarestructure}
|
||||
|
||||
% Hier vielleicht nochmal ein Verweis auf die Grundlagen, oder direkt auf die MVC-Technik
|
||||
|
||||
\section{Vergleich mit anderen Technologien}
|
||||
\label{sec:concept:technologiecompare}
|
||||
|
||||
|
@ -77,35 +80,31 @@ Damit eine Umsetzung mit einer anderen Technologie umgesetzt werden kann, muss d
|
|||
wie dies die \ac{JSP} unterstützen. Daher fallen reine FrontEnd"=Bibliotheken wie VueJS oder React aus der Betrachtung
|
||||
heraus.
|
||||
|
||||
\subsection{ASP.NET Core}
|
||||
\subsection{ASP.NET Core MVC}
|
||||
\label{sec:concept:technologiecompare:aspnetcore}
|
||||
|
||||
\mytodos{Anpassen auf "Kernpunkte"?}
|
||||
Beim Vergleich zu \ac{JSP} steht ASP.NET Core MVC in nichts nach. Im großen und ganzen ist der Funktionsumfang der
|
||||
gleiche und mit EntityFramework gibt es ebenfalls einen sehr mächtigen \ac{ORM}. Hierbei wird die Programmierung anhand
|
||||
des \ac{MVC}"=Entwurfsmuster implementiert \citep{AspNetCore:2024:MVC}. Dieses Muster erleichtert die Trennung der
|
||||
Benutzeranforderungen, welche durch die Controller mithilfe der Modelle abgearbeitet werden, von der Bedienoberfläche,
|
||||
die hier in der Standardelementen von Webseiten, wie \ac{HTML}, \ac{CSS} und Javascript definiert werden. Zusätzlich
|
||||
existiert noch ein spezifischer Syntax um die Daten dynamisch in die Seiten einzufügen.
|
||||
|
||||
\noindent
|
||||
Vorteile:
|
||||
Das System selbst ist in Schichten, auch Middleware genannt, aufgebaut \citep{AspNetCore:2024:Middleware}. Hierbei
|
||||
übernimmt jede Middleware ihre entsprechende Aufgabe oder gibt die Anfrage an die nächste Middleware weiter und wartet
|
||||
auf deren Antwort um diese and den Client zurückzugeben.
|
||||
Diese Konzept wird direkt vom Standard umgesetzt und somit sind die unterschiedlichen Verarbeitungen getrennt
|
||||
implementiert worden, was zu besserer Wartbarkeit des Programmcodes führt. Und die eigene Anwendung kann dadurch
|
||||
je nach Bedarf die Middleware aktivierten, die wirklich benötigt wird.
|
||||
|
||||
\begin{itemize}
|
||||
\item Gute Entwicklungsumgebung
|
||||
\item EntityFramework als \ac{ORM}
|
||||
\item Große Auswahl an Erweiterungen durch NuGet-Pakete
|
||||
\item Betriebssystem unabhängig
|
||||
\end{itemize}
|
||||
Zusätzlich können über eine Vielzahl an vorhandenen NuGet-Paketen das Programm erweitert werden. Oder Komponenten
|
||||
komplett ersetzt werden, wie z.B. das EntityFramework durch eine einfachere leichtere Version eines reinen \ac{ORM}
|
||||
zu ersetzt.
|
||||
|
||||
\noindent
|
||||
Nachteile:
|
||||
|
||||
\begin{itemize}
|
||||
\item
|
||||
\end{itemize}
|
||||
|
||||
Beim Vergleich zu \ac{JSP} steht ASP.NET Core nicht hinten an. Im großen und ganzen ist der Funktionsumfang der gleiche
|
||||
und mit EntityFramework gibt es ebenfalls einen sehr mächtigen \ac{ORM}. Hier sehe ich nur ebenfalls ein ähnliches
|
||||
Problem beim Caching wie bei OpenJPA, dass diese zu Problemen führen kann, wenn der Speicher voll wird.
|
||||
% Ersatz für EF?
|
||||
|
||||
C\# wird ebenfalls wie Java in einen Zwischencode übersetzt und erst bei der Ausführung auf die Zielplattform übersetzt.
|
||||
Hierbei haben die meistens Test gezeigt, dass das .NET Framework hier um einiges Effizienter und schneller arbeitet als
|
||||
C\# ist wie Java durch die neue .NET Runtime, aktuell in der Version 8 verfügbar, für die meisten Betriebssystem verfügbar.
|
||||
Bei der Übersetzung hat C\# einen Vorteil gegenüber von Java, da hier der Code wie bei Java zuerst in eine Zwischencode
|
||||
\ac{IL} kompiliert wird und zur Laufzeit über einen \ac{JIT} Compiler dann direkt in optimierten Maschinencode übersetzt wird.
|
||||
Hierbei haben die meistens Test gezeigt, dass das .NET Framework hier um einiges effizienter und schneller arbeitet als
|
||||
die Java Runtime. Zusätzlich wird bei ASP.NET Core nicht noch ein zusätzlicher Server benötigt um die Anwendung aktiv
|
||||
zu halten.
|
||||
|
||||
|
@ -129,6 +128,9 @@ Nachteile:
|
|||
\item Neue Programmiersprache, noch wenige Programmierer
|
||||
\end{itemize}
|
||||
|
||||
Die grundlegenden Ziele bei der Entwicklung von Go sind eine optimiert und vereinfachte Programmiersprache zu entwickeln.
|
||||
Hierdurch ist es sehr einfach und effizient eine Anwendung mit Go zu entwickeln.
|
||||
|
||||
Schnelle und einfache Entwicklung durch das grundsätzliche Konzept der neuen Sprache
|
||||
Ist wiederrum aber der nachteil dass es noch nicht viele können.
|
||||
Ist aber wiederrum sehr schnell und effizient und für Microservices gedacht.
|
||||
|
|
|
@ -8,12 +8,17 @@
|
|||
% Auswerten ob es einen Zusammenhang zwischen bestimmten Zeiten gibt oder ob es
|
||||
% eine bestimmte Reihenfolge gibt, bei der die Probleme auftreten
|
||||
|
||||
\section{Auswertung des Systems}
|
||||
\label{sec:performance-checking:system}
|
||||
|
||||
% Hier die Auswertung des Produktionsservers unterbringen
|
||||
|
||||
\section{Einbau und Aktivieren von Performance-Messung}
|
||||
\label{sec:performance-checking:performance-measure}
|
||||
|
||||
%
|
||||
|
||||
\section{Statistiken im PostrgreSQL auswerten}
|
||||
\section{Statistiken im PostgreSQL auswerten}
|
||||
\label{sec:performance-checking:postgresql-statistics}
|
||||
|
||||
% Logs auswerten, am besten vom Produktionsserver. Ebenfalls sollte man die Webseite
|
||||
|
|
|
@ -54,6 +54,18 @@
|
|||
urldate = {2024-03-27}
|
||||
},
|
||||
|
||||
@online{AspNetCore:2024:MVC,
|
||||
year = 2024,
|
||||
url = {https://learn.microsoft.com/de-de/aspnet/core/fundamentals/middleware/?view=aspnetcore-8.0},
|
||||
urldate = {2024-04-02}
|
||||
},
|
||||
|
||||
@online{AspNetCore:2024:Middleware,
|
||||
year = 2024,
|
||||
url = {https://learn.microsoft.com/de-de/aspnet/core/fundamentals/middleware/?view=aspnetcore-8.0},
|
||||
urldate = {2024-04-02}
|
||||
},
|
||||
|
||||
% File: 978-1-4842-3546-1.pdf
|
||||
@BOOK{Sharan2018,
|
||||
AUTHOR = {Sharan, Kishori},
|
||||
|
|
|
@ -14,6 +14,11 @@
|
|||
\acro{EJB}{Enterprise Java Beans}
|
||||
\acro{JSP}{Java Server Page}
|
||||
\acro{ORM}{Object Relational Mapping}
|
||||
\acro{MVC}{Model-View-Controller}
|
||||
\acro{HTML}{HyperText Markup Language}
|
||||
\acro{IL}{Intermediate Language}
|
||||
\acro{JIT}{Just in Time}
|
||||
\acro{CSS}{Cascading Style Sheets}
|
||||
\acro{SFSB}{Stateful Session-Bean}
|
||||
\acro{JPA}{Java Persistence API}
|
||||
\acro{API}{Application Programming Interface}
|
||||
|
|
BIN
thesis.pdf
BIN
thesis.pdf
Binary file not shown.
Loading…
Reference in a new issue