bachelor-thesis/chapters/thesis/chapter03.tex

\chapter{Konzept}
\label{ch:concept}

\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
unter \href{https://briefedition.wedekind.h-da.de} verwendet. Hierbei wird die gleiche Umfrage für Bearbeiter
und Benutzer versendet.

Die erste Frage ist zur Unterscheidung ob die Antworten von einen Bearbeiter oder von einem Benutzer kommt. Dies ist
nur notwendig, um bei der Nachstellung zu unterscheiden welche Zugriffsrechte aktiv sind.

Die weiteren Fragen sind aufeinander aufgebaut. Hierbei wird zuerst überprüft, bei welchen Aktionen eine längere
Wartezeit auftritt. Zusätzlich soll noch dazu angegeben werden, wie häufig dies auftritt, also ob dies regelmässig
auftritt oder immer nur zu bestimmten Zeitpunkten. Des Weiteren wird die Information nachgefragt, ob die Probleme
immer bei der gleichen Abfolge von Aktionen auftritt.

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.

Zuerst wird am PostgreSQL"=Server die Konfiguration der Speicher mit der Vorgabe für Produktivsystem abgeglichen.
Hierunter fallen die Einstellungen für die \textit{shared\_buffers}, der bei einem Arbeitsspeicher von mehr als 1 GB
ca. 25\% des Arbeitsspeicher definiert sein soll \cite{PostgresC20.4:2024}.

\mytodos{die anderen Speicher abarbeiten?}

Dann wird mit dem Systemtools, wie den Konsolenanwendungen \textit{htop} und \textit{free}, die Auslastung des Servers 
überprüft. Hierbei ist die CPU-Leistung, der aktuell genutzte Arbeitsspeicher, sowie die Zugriffe auf die Festplatte
die wichtigen Faktoren zur Bewertung.

Die CPU-Leistung sollte im Schnitt nicht die 70\% überschreiten, für kurze Spitzen wäre dies zulässig. Da sonst der
Server an seiner Leistungsgrenze arbeitet und dadurch es nicht mehr schafft die gestellten Anfragen schnell genug
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.

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{Das Vorgehen der Optimierung}
\label{sec:concept:optimizing}

\mytodos{Beschreibung der Untersuchung von Glassfisch? oder lieber später, oder doch eher umbennen in Ermittlung der Performance-Probleme}

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

% Vergleich mit AspNetCore und vielleicht VueJS oder Konsorten, wobei hier der Serverteil fehlt

Damit eine Umsetzung mit einer anderen Technologie umgesetzt werden kann, muss dies den kompletten Aufbau unterstützen,
wie dies die \ac{JSP} unterstützen. Daher fallen reine FrontEnd"=Bibliotheken wie VueJS oder React aus der Betrachtung
heraus.

\subsection{ASP.NET Core}
\label{sec:concept:technologiecompare:aspnetcore}

\mytodos{Anpassen auf "Kernpunkte"?}

\noindent
Vorteile:

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

\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
die Java Runtime. Zusätzlich wird bei ASP.NET Core nicht noch ein zusätzlicher Server benötigt um die Anwendung aktiv
zu halten.

\subsection{Golang}
\label{sec:concept:technologiecompare:go}

\noindent
Vorteile:

\begin{itemize}
    \item schnelle und einfache Entwicklung
    \item Native Übersetzung der Anwendung (hohe Performance)
    \item Betriebssystem unabhängig
    \item Gut geeignet für Microservices
\end{itemize}

\noindent
Nachteile:

\begin{itemize}
    \item Neue Programmiersprache, noch wenige Programmierer
\end{itemize}

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.
Reiner \ac{ORM} vorhanden, ohne weitere Caching und halten von Daten.

\subsection{PHP}
\label{sec:concept:technologiecmopare:php}

\noindent
Vorteile:

\begin{itemize}
    \item Text-Editor reicht
\end{itemize}

\noindent
Nachteile:

\begin{itemize}
   \item Script-Sprache
\end{itemize}

\subsection{Fazit}
\label{sec:concept:technologiecompare:summary}

\mytodos{Noch entscheiden, ob der Compare direkt bei der Technologie gemacht \\ wird, oder allgemein am ende}

PHP fällt aufgrund der Script-Sprache raus, da dies nicht verteilbar ist und an den Uni keine Entwickler zu finden sind.
Bei Go sind es ebenfalls hauptsächlich die nicht vorhandenen Entwickler an der Uni
ASP.NET Core ist im Vergleich zu JSP identisch, aber auch hier werden aktuell die Entwickler fehlen, da Java in den
Vorlesungen dran genommen wird.